NOTE: use Perl; is on undef hiatus. You can read content, but you can't post it. More info will be forthcoming forthcomingly.
All the Perl that's Practical to Extract and Report
--Mark Hahn, <hahn@neurocog.lrdc.pitt.edu>
Stories, comments, journals, and other submissions on use Perl; are Copyright 1998-2006, their respective owners.
Agreed (Score:1)
I agree that Perl modules should be easy to install, even by non Perl people.
Today I'm slogging through an install of the SocialText open source wiki. It's in Perl, and depends on about 100 perl modules (literally, I think).
It's taking hours to install, and needs some advanced skill to workaround the oddities coming up.
And of course, there's a great chance that the Perl modules I end up installing are not exactly the same as the developers have tested with.
This is a different ease-of-installation than
Re:Agreed (Score:1)
One is the dependency explosion. That is actually not so big a deal as long as all the modules install cleanly on all platforms, and don't have options or ask questions.
Yes it does become a problem when the dependency trees get large though, as a percentage of them will ask funny questions or potentially hit problems.
Good managers of these large projects will try to choose dependencies that are relatively light, and will also put effort into caring for their upstream, patching, fixing problems, and sometimes taking over modules as needed.
I could single out the Catalyst guys for doing a lot of good things in this regards.
The second problem, that you install different versions, actually isn't that big a deal at all. It's the reason that modules come with automated tests.
These tests are what allows all the modules to evolve independently, with minimal risk of unnoticed damage. Because if something changes, the tests will catch it, and then will be updated, or the module fixed.
Reply to This
Parent