|
Re: CPAN modules on old versions of perl?
by perrin (Chancellor) on Nov 28, 2006 at 17:25 UTC
|
if they use any third party software (comparable to CPAN modules) they know the status of every package, if it supported on their platform or not
That's just not true. Only the most popular, best supported open source Java projects actually tell you in any clear way which versions of Java they are known to run on. They don't have anything as complete as CPAN Testers, i.e. they assume that Java 1.4 will work identically on every JVM on every platform (and good luck if you believe that). CPAN Testers provides actual test reports for specific combinations of operating system and perl version.
The most popular CPAN modules, like DBI, specify which versions of perl they support. In addition, since CPAN modules usually come with tests that you can run on your own platofrm.
There is certainly more that could be done, but claiming that the automated testing system for CPAN is somehow lagging behind Java projects' totally ad-hoc and often non-existent version requirements is just wrong.
| [reply] |
Re: CPAN modules on old versions of perl? (Perl::Critic::Ancient anyone?)
by grinder (Bishop) on Nov 28, 2006 at 18:01 UTC
|
Asking authors to determine the minimum version of the perl interpreter required to run their program sounds like a lot of work, and therefore doomed to failure. You might coax a few authors into doing so by making it a measure of Kwalitee, but I can think of a better way.
Given all the Perl::Critic modules around, it might be a fun project for someone to write a Perl::Critic::Ancient, which warns about constructs that exists are available only in 5.8 or better, or only in 5.6 or better and so on. For instance, if you encounter our, the module would complain that it won't work on 5.005.
Another example: the constant module changed quite a bit over the years in what it would or would not allow, such as constant hash refs.
It might be nice to criticise code that doesn't work across a single maint version. For instance, there might be stuff that works in 5.8.8, but doesn't work prior to 5.8.4. (I have no idea if this is true, offhand).
The beauty of this approach is that, as a module, people would have a venue for reporting bugs, noting that such and such works in 5.8.7 but not in 5.8.6. Some people might even offer patches!
This also puts the burden on someone who needs to install, say, Plagger on 5.003_11 to go to the trouble of auditing themself what modules are required, and using this (on a modern installation) to find out what roadblocks stand in the way of success.
It also avoids wasted effort. What's the point of expending a non-trivial amount of effort to ensure that all my CPAN releases work on 5.002, when there's a fair chance that no-one will ever need it? I do not have the time.
On the other hand, if I received a cry for help from a lonely programmer who was battling to install one of my modules on 5.004, and gave me a report of what the offending lines were in the code, there's a better than middling chance that I just might go ahead and do it, because I would be happy to help this person out.
• another intruder with the mooring in the heart of the Perl
| [reply] |
|
|
It also avoids wasted effort. What's the point of expending a non-trivial amount of effort to ensure that all my CPAN releases work on 5.002, when there's a fair chance that no-one will ever need it? I do not have the time.
On the other hand, if I received a cry for help from a lonely programmer who was battling to install one of my modules on 5.004, and gave me a report of what the offending lines were in the code, there's a better than middling chance that I just might go ahead and do it, because I would be happy to help this person out.
Although I could see the desire to have your code be used the world-over, sometimes the cost of making things backwards compatable makes them more obfuscated and harder to maintain, or result in other tradeoffs; yes, it is possible to write things in Perl 4, but many of us enjoy the added features of Perl 5.8 and would love to see the new features of Perl 6.
I'm going to have to go against the grain on this one, and say that rather than trying to make all of the modules used behave like older versions of Perl, it'd be better (although I'm guessing vastly more complicated) to make a source filter that allows a given file to be parsed as the older version. Of course, the problem is that this would likely cause slower execution time and additional overhead.
I don't think it's a good idea to try to tie our hands and insist backwards compatability by changing the modules is the best way to go. We have newer tools, and we should use them. Decisions were made to maintain older versions of perl, and this is one of the tradeoffs. Yes, it sucks, but it's their decision on upgrading perl, and this is just one of many factors that might influence it.
* Note -- I don't have modules published through CPAN currently, but I have had to deal with management who wouldn't allow me to upgrade code that needed it -- I just went and installed multiple versions of perl, and made sure that the libraries I wrote worked in both versions. The only problems I remember having was some quirk with Net::LDAP, and I just went and got an older version, so the two matched, as management didn't give me enough time to analyze what had gone wrong
| [reply] |
|
|
yes, it is possible to write things in Perl 4
Maybe so, but modules don't exist in Perl 4, so the issue is moot.
The point I was trying to make is that I hold the code I publish on CPAN to a to a higher standard than the code I write from day to day. The former should be able to run on a wider range of perl interpreters, the latter could quite easily be tied to a single release.
The Perl syntax understood by perl 5.8 is not radically different to the syntax understood by perl 5.000. Yes, there have been lots of nice little tweaks and fine-tuning over the past 12 years, but nothing that has fundamentally changed the language. (ok, $coderef->() is really nice, and the alternative is awful).
It's not particularly difficult to write code that avoids 5.8-isms. I don't recommend this as a regular technique, but in code for CPAN, it means the code works for a wider audience.
I think chromatic under-estimates the longetivity of business installations. At my previous place of work, they're probably still using 5.003. Currently at work, some of my mission-critical systems rely on 5.6. They will probably continue to do so until they are retired. Life is too short to upgrade perl continually, just to ensure that I'm running on a perl released less than two years ago. It just ain't gonna happen.
Again, I don't recommend that people write in a 5.003-compatible syntax. Write in 5.10 syntax, and use defined-or, state variables and the underscore prototype if you want. Write in what you feel comfortable with.
But it would be really nice to have a Perl::Critic module that examines your code, and points out what parts won't be recognised by a 5.8.x interpreter, what parts won't by a 5.6.x interpreter and so on. It would be a fun project I think, for someone with more tuits than I, and it's certainly something the Perl community could be proud of. Something we could hold up and say "See? Java, PHP, Python, Ruby... they have nothing like this! You can audit code and find out what the minimum perl interpreter is needed to run it."
And it would be Good.
• another intruder with the mooring in the heart of the Perl
| [reply]
[d/l] |
|
|
| [reply] |
Re: CPAN modules on old versions of perl?
by jmcnamara (Monsignor) on Nov 28, 2006 at 19:08 UTC
|
| [reply] |
Re: CPAN modules on old versions of perl?
by davorg (Chancellor) on Nov 28, 2006 at 16:38 UTC
|
Maybe META.yaml needs to include information about the minimum version of Perl necessary. Then that information could be used in CPAN searchs.
--
< http://dave.org.uk>
"The first rule of Perl club is you do not talk about
Perl club."
-- Chip Salzenberg
| [reply] |
|
|
| [reply] |
|
|
do CPAN authors know the minimum perl required for their modules?
I would hope so. But what they might not know is the minimum Perl version for all of their prerequisite modules. But if each module knows a) its minimum version and b) all of its prereqs, then something like CPANPLUS (or, perhaps, CPANTS) could walk the tree and tell you if one of your prereqs needs a more recent version that the one that your are currently reporting.
What about old modules such as Net::Telnet will anyone release a new version of it just to include the META.yml
Maybe if it became a kwalitee measure :-)
--
< http://dave.org.uk>
"The first rule of Perl club is you do not talk about
Perl club."
-- Chip Salzenberg
| [reply] |
|
|
|
|
Re: CPAN modules on old versions of perl?
by Scott7477 (Chaplain) on Nov 28, 2006 at 19:34 UTC
|
Looking at the test reports that are gathered in the testers.db at CPAN-Testers, I note that submitted test results include a line specifying the version of Perl that the test was run under. I think that the OP's suggestion would be an effective way to provide the information he is talking about.
I'll rephrase it in the form of a spec just to make sure I understand what I am saying here:
CPAN Module--Perl Version Compatibility Checker
1. new functionality at testers.cpan.org in the form of a link on the home page to a page with a list of perl versions
2. a link from the new page referenced in 1 above to a page with a list of platforms
3. links on the new page referenced in 2 above to a page for each platform
4. on each platform page have a search box form where the user keys in the module they are looking for and the form returns a list of all test results that have been submitted for the module in question
Needless to say, this would require some tweaking of the SQLite database that CPAN-Testers are using. (caveat: obviously this would require some work, so by posting this I might seem like I'm volunteering:). I would actually be willing to work on it but couldn't promise quick results).
With regard to older versions of Perl, anyone who has looked at the cpan-testers mailing list recently can't have failed to notice the huge volume of test reports that bingos and others are generating. It is my understanding that bingos has concocted some code that is allowing him to generate these prodigious amounts of tests automatically. Should he choose to share his work with the Perl community at large, I think it wouldn't require a huge community effort to generate a largely complete set of test results for older versions of Perl, which would allow folks still stuck with old versions of Perl to get value out of this hypothetical
system we are talking about here.
What does the monastery think? Am I off base here? | [reply] |
Re: CPAN modules on old versions of perl?
by geekphilosopher (Friar) on Nov 30, 2006 at 22:46 UTC
|
This could be a good idea. We run a customized version of perl 5.6 here at work, and though we're a bit stringent with our CPAN usage this idea would still be useful. | [reply] |
Re: CPAN modules on old versions of perl? (cXXXpan)
by Anonymous Monk on Nov 12, 2014 at 03:48 UTC
|
| [reply] |