[Whoops -- somewhere along the line Adam and I stopped CC'ing the list. I'd meant my reply to go to all, so I'm forwarding it below.]
On Nov 19, 2007 8:10 AM, David Golden <[EMAIL PROTECTED]> wrote: > On Nov 19, 2007 3:12 AM, Adam Kennedy <[EMAIL PROTECTED]> wrote: > > ExtUtils::MakeMaker is one of them, and the one that I think seals the deal, > > because it's basically not back-compatible, or at least we end up with > > ($ExtUtils::MakeMaker::VERSION... ) ? ( ... ) : () inside the prereq_pm key > > (presumably...). > > There are plenty examples of that syntax today. Moreover, adding a > new key to META.yml doesn't change that, as module users' machines may > not have up-to-date PERL_VERSION compatible EU::MM. From a design > flaw perspective -- the fact that the META.yml and dist tarball > generator is the same codebase that end-users need to have installed > just to make/test/install a module seems to be the bigger problem. It > effectively prevents substantial innovation for module authoring in > order to preserve compatibility with those installing. > > > There's been niggly issues with Module::Install as well, because of the > > special handling required. > > There's been niggly issues elsewhere because of Module::Install -- > e.g. CPAN.pm set PERL5_CPANPLUS_IS_RUNNING *and* > PERL5_CPAN_IS_RUNNING? M::I is actually the easier thing to fix > without compatibility issues than the rest of the toolchain since > affected module authors only need to upgrade M::I and re-release. > > I just don't accept EU::MM and M::I as sufficient "number of > incidents" to justify. > > > Well, firstly, I want to see universal declaration of minimum Perl versions > > needed in metadata. > > > > perl_version is (in my opinion anyways) better for this. > > You won't get "universal" until all CPAN adds it. You have a place > where it's being declared in metadata by many modules today. The last > statement isn't a use-case, it's just a design opinion. > > > Even if MY modules have a 5.005 declaration, I'd like to see the graph of my > > deps and auto-magically scan to see none of my deps have higher perl version > > deps than mine. > > How is this different with a perl_version:5006 key versus a > requires:perl:5006 key? At the end of the day, it's still just > interrogating a META.yml file to pick out a number. > > So your use case analysis is: > > * universal perl version in metadata (check, already there today for > many modules and could be added similarly by any others that define > it) > > * be able to scan dependencies for perl version (check, already possible > today) > > > For example, did anyone else notice the IO::Zlib release today? > > > > It adds a 5.006 minimum, which impacts Archive::Tar and a few other > > components of Bundle::CPAN, which basically means the CPAN toolchain just > > lost 5.005 support. > > I didn't see the 5.006 part -- but that's OK since Schwern just > declared the 5.005 toolchain dead anyway. (Thank god for benevolent > dictators -- if nothing else, Slaven should get credit for the > "assist" on making that happen.) > > > I only just happened to notice that, but I'd like to see some level of > > automation/management of this sort of stuff. > > > > This is MY main use case... > > Which would be possible today if IO::Zlib added "requires:perl:5.006" > to its META.yml. > > One problem is that IO::Zlib uses Makefile.PL and EU::MM doesn't like > "perl" in PREREQ_PM (though it *does* write it the Makefile PREREQ_PM > and to META.yml, so it works, but it's noisy about it). I even > offered a patch (and test file) for EU::MM on RT back in July: > https://rt.cpan.org/Ticket/Display.html?id=28374 > > Schwern (or someone's) suggestion of a perl.pm hack to silence older > EU::MM's that have to consume perl in the PREREQ_PM would take what, > 15 minutes to write, test, tarball and upload? Yes, it's a hack. But > it's a simple, limited hack. > > So with maybe 30 minutes of work to apply the patch to EU::MM and to > release perl.pm, all your use case needs (already satisfied) even > become user friendly. > > Then you just have to evangelize putting "perl" into the requires > section and your universal metadata is on the way. > > We've probably spent more time debating this issue than it would have > taken to apply the patch and write perl.pm. > > David >
