search

Perl-Toolchain-Gang / CPAN-Meta

Specifications for CPAN distribution META files
36 stars 40 forks source link

Separate 'perl' version requirement metadata #103

Open Grinnz opened 8 years ago

Grinnz commented 8 years ago

'perl' is not a normal prerequisite, so it should have its own metadata field separate from 'prereqs'. Namely, 1. it should never be installed by the CPAN installer, so it can only cause installation to fail, and following from that 2. suggests/recommends for 'perl' makes no sense in the context of the CPAN installer. Having the field be a regular Version Range as it is in the prereqs object would be sensible.

Leont commented 8 years ago

I don't think we can do anything with it on the runtime-configure-build-test axis, but I do think it could be useful on the requires-recommends-suggests axis, if only to communicate to the end-user.

Grinnz commented 8 years ago

I would consider documentation a more than sufficient place to communicate a recommended perl version; I cannot think of a tool that would benefit from having that information in metadata.

karenetheridge commented 8 years ago

I don't think we can do anything with it on the runtime-configure-build-test axis

The cpan client could inspect that before running Makefile.PL, so as to disqualify a distribution for install earlier; presently it doesn't find out until it runs Makefile.PL and hits a use 5.024; statement.

Grinnz commented 8 years ago

But runtime/configure/build/test is definitely not a useful distinction for required perl version, forgot to mention that in the original comment.

karenetheridge commented 8 years ago

This could be prototyped as:

    x_perl => {
        requires => '5.010',
        recommends => '5.012',
        suggests => '5.022',
        conflicts => '>= 5.023005',  # just for completeness - but this could indicate e.g. "definitely doesn't work there as there are breaking changes in XS"
    }
Leont commented 8 years ago

What practical problem would be solved by this? How would this change make software simpler at this stage?

rjbs commented 8 years ago

That's exactly my question, too. Handling "perl" in the prereqs is a solved problem.

haarg commented 8 years ago

I don't think there is any real gain by trying to split perl out at this point. Having perl included in the standard prereq section may not be entirely consistent, but it is well established and is handled by everything already. I can contrive situations where a test recommends on perl would make sense, and I don't see the harm in allowing things like test requires being different from runtime requires.