Over on module-build@perl.org there's a bizarre argument going on over changing how you declare the minimum version of perl in META.yml. Currently it's an ambiguous, undocumented special case of the "requires" mechanism which is supposed to only be for modules. Folks want to make it it's own key.
The bizarre part is folks are blocking this as a backwards compatibility thing. That if we add a new key to META.yml those using old tools won't be able to parse it. David Golden put it this way...
> CPAN author: "Why are you complaining that my module doesn't work on
> 5.6? I clearly put 'requires_perl' in the META.yml"
>
> CPAN user: "My $job still uses 5.6.s and doesn't let us install newer
> versions of @toolchain_modules"
As to this, I'll paraphrase chromatic. Why are we worrying about the effect of upgrades on users who don't upgrade?
Hell, we're not even saying "upgrade perl", which can be a major event. We're just saying "upgrade some toolchain CPAN modules which we've painstakingly released separately from perl itself and ensured still run on your seven year old version of perl". Come on, meet us halfway here. Quarter of the way? Can you at least come down at meet us at the door?
Paradoxically, the more we bend over backwards to support users who are being blocked from upgrading, the harder it is for them to upgrade. Huh?
I've been in that situation where $job won't allow an upgrade. Usually the problem is that $job doesn't want the programmers spending time (and thus, money) on a task which they perceive as having no business value. Thus the programmers must justify the upgrade in terms of business value. For example, if the company decides to start doing work in Japan you might cite the improved Unicode features of 5.8. Barring a home run like that, what's left?
The constant problems installing new CPAN modules on old perls is one. Every time you have to patch around incompatibilities with your old perl a little bit of money goes *poof*. Add them all up and you've got a business case for upgrading perl.
But what it really boils down to is this: Who's more important: Some users who won't upgrade or all your future users? How many future users are you willing to inconvenience (and possibly lose) to avoid inconveniencing those who won't even keep up to date? Backwards compatibility is important, but there's a limit to how far you should drag people along who don't want to go. Not at the expense of moving forward, always improving.
I heard that story about make, specifically the leading tabs.
Re:C or Make?
schwern on 2007-11-21T01:06:37
I think you may be right.
Firstly, thanks for pointing out there is a discussion about something that is potentially of interest to the WHOLE of CPAN and not just a small subset. Wouldn't it be better to have a specialist list regarding META.yml specs, that discusses these sort of changes? A Module::Build list is not something I am going to sign up as I tear my hair out with MB at the best of times.
When I first saw your post, I assumed this was part of the Module Authors list discussion a few weeks ago, but struggled to find the thread, then looked back at your post and realised my mistake. While I'm not sure Module Authors is the appropriate place, it would be more appropriate as I suspect more authors read it.
Secondly, while I'm inclined to agree with your sentiment about users who don't upgrade, this particular issue seems a strange one.
If your reason for creating a key is to highlight something that is essentially an executable (or a library for that matter), then then I would have to agree creating it is a worthwhile exercise. This could then lead to others supporting the META.yml spec who are non-Perl, such as for Python, PHP or Ruby distributions (don't know if they exist at the moment, but I see no reason why they shouldn't, and for them to have a similar toolchain to install them). However, I do think requires_perl is not appropriate, requires_executable using the same format as the requires would be more useful.
There has long been a discussion about supporting libraries and a requires_library would be a suitable companion to requires_executable. Yes it would mean that a number of tools would need to change and it might be painful for authors in the short-term, but as most CPAN Testers are the ones likely to find the problems and be reporting them, it could be managed.
Re:Conflicts of Interest
Alias on 2007-11-20T01:18:14
The main issue here is that META.yml is not authorative, with the exception of the configure_requires key.
You need to run Makefile.PL in order to determine the configuration (and thus dependencies) for that host.
Thus, META.yml is considered to be advisory only.
New and useful keys in META.yml are those that are likely to be useful in an advisory context.
Knowing the minimum Perl version meets this criteria, as useful things can be done by mapping dependencies at a graph level and working out which modules are blocking back-compatibility of their dependencies, etc etc.
It's very common for Makefile.PL to do interesting and unusual things regarding search for libraries, so while somewhat interesting, the usefulness of a requires_library in an advisory context is somewhat reduced.Re:Conflicts of Interest
schwern on 2007-11-21T01:16:06
However, I do think requires_perl is not appropriate, requires_executable using the same format as the requires would be more useful.
I came to that conclusion, too, but from a desire not to have a whole salad of "requires_perl", "recommends_perl", "test_requires_perl", "configure_requires_perl", etc...
The trouble is a general purpose executable/external utility specification is a whole lot more difficult. Previously, everything in the META.yml was about the module being shipped. Now we want to specify things that aren't under Perl's control. And then things rapidly get meta. What if I just need a mail server? You don't want to hard code an executable, you want to say "mail server". Debian has this in the form of its "provides" key and the idea of virtual packages. But Debian controls the operating system, we don't.
So, pragmatically, requires_perl is a simple solution to an existing problem that we can implement now whereas requires_external or a big mess.
