I'm finding it hard to evaluate this, so I'll just list the thoughts that occurred when reading it:
I've done some work on the guts of IO::All as well as added a variety of features lately. I'd really like this to happen and think that it would be a good benefit for the community in general.
Full disclosure: I'm a sometime-contributor to IO::All, and a fulltime user of it.
I am entirely of the opinion that this grant should be granted, since IO::All is the io library Perl needs.
Neil, to answer your concerns:
> The bullet list in the Benefits section is hard to argue with, but I don't get any sense of how well the existing distribution meets these.
IO::All is fairly old, and was mainly written with an eye to making the API work right. For the bullet points it fulfills pretty much 90% of each, but to get the remaining 10% necessitates large-scale refactoring of the guts of IO::All.
> How many dists rely on this dist? MetaCPAN says 96, and my slightly-out-of-date database says just over 400 total dependencies (direct + indirect).
I don't know about CPAN, but i do know that i use it in every piece of code of my work where i'd otherwise need to directly do an open(), which is a lot of production code; and i mandate junior devs working on projects with me use it, which usually results in their code being more reliable and more readable.
> What are the problems that the dependent dists are having that necessitate a rewrite?
> Is there anyone saying they'd like to use IO::All in production, but feel they can't?
A few points that keep others from using it, based on feedback i got by talking to people on IRC:
- homebrew OO system
- magic: automatic type detection when doing io($thing)
- magic: overloads of things like > and Pretty much every dist of mine on CPAN, when I look at it I think "*cough* that could do with a rewrite", but actually they're fine for the intended job, and could just do with some refactoring over time. Why is that not the case here?
As mentioned, in this case refactoring means replacing all of the base code while keeping the API mostly as it is. There simply is no way to do this piece-a-meal.
There's been discussion on and off about rewriting IO::All to be cleaner and easier to extend. The intent, here, is to provide the swiss army chainsaw of IO modules, i.e. "what you use when Path::Tiny is more minimalist than you had in mind", which IO::All largely already is for my purposes, but for it to be so for people in general.
So, many of us are already using it in production, but believe that a rewrite to be more consistent, clear and comprehensible, and to make it easier for a true ecosystem to form around the distribution, would be a significant net win.
It'd be nice to be able to finally kill uses of e.g. Path::Class with a clear statement of "for simple stuff, there's Path::Tiny, for complex stuff, there's IO::All", and I believe this rewrite will put us within reaching distance of that.
I have to second what Neil said. There is potential here, but the proposal is too vague in both its problem definition and in its suggested solution.
"All things are done safely" and "Unicode issues are all handled correctly" sounds great, but what does that really mean? For example, are you planning to change the interface to make things safer and saner?
Generally I do recognize the list of issues I'd like to see fixed that Christian mentions.
Makoto asked me to write a followup reply to these comments.
I/O is one of the most core features of a programming language. I think it is a decent analogy to say that IO::All wants to be for open() what Moose is for bless(). Having a simple and consistent way to do all I/O and filesys operations is a good thing for Perl. IO::All is a great start, but it was done as a proof-of-concept in 2004, and needs to be redesigned. The thought on how to do it and release it in a way that doesn't break existing code has happened and been discussed on #io-all IRC channel for years now. I linked to a design overview in the proposal.
To reply directly to some of the points raised by neilb and leont:
1) Based on the experience of the Inline grant and the known amount of work and thought to do this, the pay rate of $4000 will come in at much less than minimum wage. In this case, the grant is a carrot to get something really good finished for Perl, and the rate is as low as I could possibly justify for other parties interested in my time.
2) Dists depending on IO::All is a wrong comparison. Almost all my Perl scripts use it. Few of my modules do, as I try to keeping dependencies low on my dists.
3) While not a complete spec, https://raw.githubusercontent.com/ingydotnet/io-all-pm/master/note/Design.swim is hopefully not _vague_.
I hope this helps. I'd like to thank mst, frew and Mithaldu for their supporting comments and work on IO::All over the years. More than getting this grant accepted, I really wish personally that this work was already done. I'd enjoy using it in my Perl coding every day.