(But as I stated in the reply to lestrrat, having configure_deps for build tools like M::I/Dist::Zilla is wrong, because it's not necessary once shipped to CPAN)
cpanfile is a convenient format to have the canonical information about CPAN deps of your apps/modules that are not in CPAN-compat format (yet), and nothing else.
Everyone who gets it seems to like it :) I haven't promoted the format enough since i first announced at LPW 2011, particularly because my build tools (cpanm, carton) haven't had the full support for that yet. With cpanm 1.6 released and carton 1.0 in the pipeline, i will need to give a new talk in more conferences to promote that.
Once again, this is opt-in and not a requirement at all for CPAN authors. Using cpanfile (as a CPAN author) will still work with standard CPAN installers through the use of META->MYMETA compat layer such as Module::Install::CPANFile or Module::Build::Pluggable::CPANFile.
It's similar to how dzil users manage deps in dist.ini (or auto-extracted from scanner, which I'm not a big fan of), but dump META.yml when shipped to CPAN.
]]>While this is a good blog post, I don't think the use of cpanfile to stick git deps for your CPAN module is the primary purpose. cpanfile is for apps to pin CPAN deps without dealing with the MakeMaker or Build at all.
The ability to manage CPAN deps in the git (without committing META) is an accidental, secondary feature. Even yet, using `configure` phase for the build tools is wrong, and I hope we can switch to develop sooner.
Apologies for flooding comments.
]]>I really like the concept of cpanfile for non-CPAN projects, I agree that having a "fake" Makefile.PL just to be able to do cpanm --installdeps on it is unnecessary.
That said, for projects destined for CPAN, part of the reason that I still prefer a real Build.PL and associated vagaries, rather than dzil or other author-side build tools is that being close to the actual releasable dist allows others to jump in with less cognitive dissonance. The oddities of my dist.ini are not involved, there is no magic. My git repo is almost what you get from CPAN. I understand that's not for everyone, but I like it and I like when I go to contribute to some other project when I can jump in an work with no barrier. Then again, I'm sure other prefer cpanfile or dist.ini to Build.PL. Oh well.
Cheers
]]>That's exactly my point :)
> Then again, I'm sure other prefer cpanfile or dist.ini to Build.PL. Oh well.
It makes me giggle reading your comment, because you know what, my next target is to integrate LeonT's Module::Build::Tiny to work well with cpanfile, so that you have a real Build.PL in the repo that works transparently with cpanfile + MYMETA protocol, to get the best of both worlds :)
I encourage everyone (I'm talking to me too) to ++ the modules you use regularly, it really can help the signal to noise.
(But don't use it to the exclusion of others, who knows where that next diamond in the rough will come from)
]]>As to the Socket vs. Socket6 question: Originally, Socket6 was written by someone to provide the various IPv6-related functions missing from core's Socket. Eventually I got around to taking over core's Socket and adding them properly there where they should be. This now makes the Socket6 module totally redundant. Should that now be marked? If so, where? I have no write access on Socket6, so I can't write it there. I could notate it in Socket, if anyone would think to look there. Finally, I could ask Socket6's author to "hi, you wrote this thing, but it's now totally redundant and not necessary; please delete it". I don't feel that will go down well at all.
However, most users should never need to do much poking around with Socket directly, as that's what the higher-level object wrappers are for. Which brings me on to my next point...
I wrote IO::Socket::IP to fix various shortcomings in ::INET6, which I felt didn't implement IPv6 wrapping properly. ::INET is the specifically IPv4-only module. For reasons that much existing code expects that ::INET only ever deal with IPv4 addresses, that module cannot be changed to use IPv6 as well. Finally, IO::Socket is a base class that exists only for specific protocol modules to subclass to provide things like this.
So my question to you is simple: In each of Socket, and IO::Socket::IP's cases, what should I as the author have done? How can I have helped the situation, providing more information, and avoided the doubt you initially raised?
]]>Other than voting, metacpan or cpan site should include a counter that tells how many times a particular module has been installed or downloaded. This is one of the measurement used by many users when there is a huge catalog. For example, mobile apps installed from app store has this counter, the greasemonkey scripts installed from userscripts.org has something similar.
What I believe, is CPAN model should be similar to Mobile app store, where the app store gives information like; reviews, rating, no of downloads, other modules by author, suggested modules and so on.
Calm down. Some of the ideas are META improvements, but I think the bulk of the fixes would be the first two ideas: search engine improvements and better ways of handling abandonment. These are things that we can do right now, and yes, I'm trying to work on these myself. I just wanted a better idea as to the receptability of the problems and how to solve for them. Before I, say, work on an entire automated abandoned status checker and have the whole concept be rejected by the modules@ team.
So my question to you is simple: In each of Socket, and IO::Socket::IP's cases, what should I as the author have done? How can I have helped the situation, providing more information, and avoided the doubt you initially raised?
I'm not really blaming you. I'm not trying to blame anybody. The situation is what it is. It's hard to control these kinds of depreciation issues when you don't control all of the modules. (And even when you do control them, there's still the issue of backwards compatibility with former users.)
I was just using your example to illustrate the confusion caused by a new user who is trying to figure out which Socket module is best, and overall, I'm trying to figure out some potential solutions.
Other than voting, metacpan or cpan site should include a counter that tells how many times a particular module has been installed or downloaded.
This is rather difficult since everything is installed via mirrors. That doesn't even include the Debian/RedHat modules, or other bundle packs.
]]>> I am constantly and consistently surprised about how many
> people do not first try to work with existing projects.
For me, GitHub has been the single biggest factor in lowering the barriers to entry to making contributions to existing CPAN modules. I find I'm far more likely to contribute changes to an existing module when all I need to do is fork it and send a subsequent pull request. Maybe if more source code was handled via GitHub (or similar mechanism) there might be less of a tendency to reinvent the wheel as opposed to enhancing existing code.
]]>I think the debate over base vs parent is a great example of where the lines are blurred. Peter says:
> The "fields support" slowing down base.pm is a myth. Please read what Brendan linked and consider adjusting your reality distortion field:
I did read what Brendan linked. I didn't take away from that that I should use base instead of parent at all. What I took away was that a) I should never try to use both in the same project, and b) while base is no longer slower than parent, it almost certainly takes up more memory than parent. So, as long as I make sure no `use base`s are slipping in, I still don't see any compelling reason to stop using `use parent`.
But the point is, you have the choice on CPAN, and choice is good. Except when it's not. Which I suppose is the point of this blog post ...
But, really: carry on. Everyone wishes it was better. Even the people who bitch you out. :-D
]]>You have to strike a balance though, I've seen a 10k line if/then/else chain CGI, that had 0 abstraction. It's often faster to write 0 abstraction, and slower to write more abstraction, though more will get you places in the long run.
In some cases here in perl land I find that we lack the appropriate tools (for all them modules that exist) to do it right quickly.
@Al, interesting thought on why personal projects are hard to complete... I wonder what the solution to it is.
]]>Do you know if this still works for cpanm and/or Carton, and what the proper syntax is for it? cpanm keeps trying to read the url as a version number, no matter how I enter it.
]]>