Re: Module::Install is a time bomb
Michael G Schwern [EMAIL PROTECTED] writes: Module::Install is the greatest threat to CPAN stability. So why not get rid of it? If it does not provide any relevant functionality that EU::MM and M::B also provide, it should be possible to convince the author to withdraw it. -- Johan
Re: Module::Install is a time bomb
On Tue, Sep 30, 2008 at 10:23 AM, Johan Vromans [EMAIL PROTECTED] wrote: Michael G Schwern [EMAIL PROTECTED] writes: Module::Install is the greatest threat to CPAN stability. So why not get rid of it? If it does not provide any relevant functionality that EU::MM and M::B also provide, it should be possible to convince the author to withdraw it. Personally, I wonder how many authors use it because of the bundling capability and how many use it for the simple declarative syntax for Makefile.PL. -- David
Re: Module::Install is a time bomb
On Tue, Sep 30, 2008 at 1:53 PM, Ben Morrow [EMAIL PROTECTED] wrote: I use it both for the declarative syntax and because it allows me to type /path/to/perl Makefile.PL make test in a dev directory with a fresh install of perl and get all the dependencies installed for me. Since I keep lots of versions of perl around and try to test my modules on all of them, this is highly convenient. Is that with auto-install? I guess I can see that purpose, though auto-install can be a real annoyance to end-users otherwise. I'd probably do it this way with a recent version of CPAN.pm: $ /path/to/perl -MCPAN -e shell cpan test . No Module::Install or auto-install required. -- David
The problem with auto-installing dependencies
Since anyone can upload code to CPAN, not all modules are of the same high quality as others. I feel it is very important to vet each and every module that I install. But with the auto-install behavior, modules that I want to install may have dependencies on other modules that I don't feel comfortable installing, and I want to have the opportunity to consider each one before I go ahead and install it. So I don't like auto-install. I want it to stop and complain that the other module is missing, so I can go over to the CPAN Web site, look up that module, see who wrote it, read its documentation, scan its code, and get a feel for whether I'm comfortable installing it before doing so.
Re: The problem with auto-installing dependencies
* Bill Ward [EMAIL PROTECTED] [2008-09-30T15:12:22] Since anyone can upload code to CPAN, not all modules are of the same high quality as others. I feel it is very important to vet each and every module that I install. But with the auto-install behavior, modules that I want to install may have dependencies on other modules that I don't feel comfortable installing, and I want to have the opportunity to consider each one before I go ahead and install it. So I don't like auto-install. I want it to stop and complain that the other module is missing, so I can go over to the CPAN Web site, look up that module, see who wrote it, read its documentation, scan its code, and get a feel for whether I'm comfortable installing it before doing so. I wish I had that kind of free time. Try setting the env var PERL_AUTOINSTALL to --check or --skip. Or --check,--skip q.v. http://search.cpan.org/src/ADAMK/Module-Install-0.77/lib/Module/AutoInstall.pm -- rjbs
Re: The problem with auto-installing dependencies
On Tue, Sep 30, 2008 at 12:46 PM, Ricardo SIGNES [EMAIL PROTECTED] wrote: * Bill Ward [EMAIL PROTECTED] [2008-09-30T15:12:22] Since anyone can upload code to CPAN, not all modules are of the same high quality as others. I feel it is very important to vet each and every module that I install. But with the auto-install behavior, modules that I want to install may have dependencies on other modules that I don't feel comfortable installing, and I want to have the opportunity to consider each one before I go ahead and install it. So I don't like auto-install. I want it to stop and complain that the other module is missing, so I can go over to the CPAN Web site, look up that module, see who wrote it, read its documentation, scan its code, and get a feel for whether I'm comfortable installing it before doing so. I wish I had that kind of free time. It's a big part of my job to ensure that our tech stack at work doesn't get corrupted by bad code. Try setting the env var PERL_AUTOINSTALL to --check or --skip. Or --check,--skip Thanks, I'll keep that in mind.
Re: The problem with auto-installing dependencies
On Tue, Sep 30, 2008 at 11:02 PM, Bill Ward [EMAIL PROTECTED] wrote: On Tue, Sep 30, 2008 at 12:46 PM, Ricardo SIGNES [EMAIL PROTECTED] wrote: * Bill Ward [EMAIL PROTECTED] [2008-09-30T15:12:22] Since anyone can upload code to CPAN, not all modules are of the same high quality as others. I feel it is very important to vet each and every module that I install. But with the auto-install behavior, modules that I want to install may have dependencies on other modules that I don't feel comfortable installing, and I want to have the opportunity to consider each one before I go ahead and install it. So I don't like auto-install. I want it to stop and complain that the other module is missing, so I can go over to the CPAN Web site, look up that module, see who wrote it, read its documentation, scan its code, and get a feel for whether I'm comfortable installing it before doing so. I wish I had that kind of free time. It's a big part of my job to ensure that our tech stack at work doesn't get corrupted by bad code. On one hand if you trust and want module X then I would guess you don't have much choice but to trust and install all its dependencies so there is not much point in checking each module. On the other hand I wish we could use your findings either as CPANRATINGS or better yet through some not yet existing system where each one of us could say which authors do we trust or which specific modules do we trust and then also which users do we trust to use their opinion. The web of trust that has been discussed lately on several channels. After all you are doing some work we all wish we had time to do throughly when we decide on using a module. regards Gabor -- Gabor Szabo http://szabgab.com/blog.html Test Automation Tipshttp://szabgab.com/test_automation_tips.html
Re: Module::Install is a time bomb
On Monday 29 September 2008 10:59:09 Michael G Schwern wrote: Matt S Trout wrote: use inc::Module::Install; I will say it again: Module::Install is the greatest threat to CPAN stability. s/Module::Install/Autobundling/ Autobundling is fine for end-user all-in-one no-user-servicable-parts-inside applications, but the CPAN is not the place for static linking. It would be nice not to drag Perl kicking and screaming back into the 1970s. I'm still trying to figure out what's the problem with adding '0.31' to the 'use Module::Build;' line in a Build.PL, and how autobundling could possibly be ever a good idea in a CPAN distribution. -- c
Re: Module::Install is a time bomb
2008/9/30 Michael G Schwern [EMAIL PROTECTED]: That said, people choose based on convenience, not abstract, long term safety. So it's for the best that Module::Build absorb every convenience feature from MI. For the record, I concur entirely with this solution. Module::Install was a step forwards for adding new functionality to configuration scripts given the alternatives. Since these arguments often go in circles, a quick reminder where we are right now. ExtUtils::MakeMaker Change Solution: Never change, bug fix as lightly as possible. Short Term: Just Works, authors need lots of if ( $] = 5.005 ) cruft Long Term: Slow death by obsolescence. Module::Build Change Solution: All users hand-upgrade without being told when Short Term: Modules don't build on the default Perl install Long Term: New features can't be used + OMGIBROKECPAN kills CPAN till every user upgrades. Module::Install Change Solution: Bundle everything, assume the author releases a lot Short Term: Works Fine Long Term: Old Releases go toxic + OMGIBROKECPAN kills CPAN till every author upgrades (or the modules are taken over). configure_requires: Change Solution: Client knows when to upgrade toolchain Short Term: Needs 100% support from toolchain, THEN we tell users just upgrade Bundle::CPAN (a current somewhat learned behaviour when installs break anyway) Long Term: configure_requires available in the default install from 5.8.9 and 5.10.1. Just Works. I'd be more than happy to shift Module::Install over to Module::Build, or (more likely) to have a clone of the far nicer interface that sits on Module::Build. It's just that Module::Build fails now, and Module::Install fails later (but more dramatically). And I'm biased towards things working now, as long as everyone is clear that it's just a workaround now, till the better option is delivered. Now that M:B and EU:MM and M:I and CPAN.pm all support configure_requires, it is safe to start telling CPAN.pm users just upgrade your Bundle::CPAN. I just don't want to make a lot of noise about this until we finally get CPANPLUS over the line, and have everything synced to core for the next releases. Jos says that CPANPLUS svn is fairly close to being stable, and wants people to test it. The faster we can get the next CPANPLUS stable over the line, and everything synced back to core, the faster we can start the clock on the 1 year that we still need to tread cautiously but generally can just tell people to upgrade Bundle::CPAN. Adam K
Re: Module::Install is a time bomb
2008/9/30 Michael G Schwern [EMAIL PROTECTED]: chromatic wrote: s/Module::Install/Autobundling/ Autobundling is fine for end-user all-in-one no-user-servicable-parts-inside applications, but the CPAN is not the place for static linking. It would be nice not to drag Perl kicking and screaming back into the 1970s. Autobundling is fine AS LONG AS the bundled version gives way to a newer installed version. I suspect needs to be a little bit more robust than just giving way because that doesn't give you proper reach back in time capability. Really, inc::Module::Build needs to not only be able to know that the installed one is newer than it, but that if that is the case it should use an entry point to loading Module::Build specifically for that it. That would avoid cluttering up the regular M:B bootstrap, and let you concentrate all the compatibility weirdness for handling old bundled stuff in one separate place. So then you get use inc::Module::Build; ... which loads... use Module::Build::BundleCompany; ... which then has the option of doing various things before actually loading... use Module::Build; ... and returning back to the Build.PL code. The key theme to all this new stuff is that it should be able to reach back in time on it's own and pull forwards anything we don't currently know is broken. Making a specific place for current-MB to trigger future-MB seems like a nice extra safeguard, since we have the chance to build it in from the beginning. Adam K
Re: Module::Install is a time bomb
Quoth [EMAIL PROTECTED] (David Golden): On Tue, Sep 30, 2008 at 10:23 AM, Johan Vromans [EMAIL PROTECTED] wrote: Michael G Schwern [EMAIL PROTECTED] writes: Module::Install is the greatest threat to CPAN stability. So why not get rid of it? If it does not provide any relevant functionality that EU::MM and M::B also provide, it should be possible to convince the author to withdraw it. Personally, I wonder how many authors use it because of the bundling capability and how many use it for the simple declarative syntax for Makefile.PL. I use it both for the declarative syntax and because it allows me to type /path/to/perl Makefile.PL make test in a dev directory with a fresh install of perl and get all the dependencies installed for me. Since I keep lots of versions of perl around and try to test my modules on all of them, this is highly convenient. Of course, if someone were to make all that work using M::B as the backend instead of EU::MM, I would be perfectly happy. Probably more so, as then extending M::I wouldn't require messing around with EU::MM's mess and the hacks required to make M::I work on top of that. Ben -- If you put all the prophets, | You'd have so much more reason Mystics and saints | Than ever was born In one room together, | Out of all of the conflicts of time. [EMAIL PROTECTED]The Levellers, 'Believers'
Re: Module::Install is a time bomb
[just sent to module-authors, as this is hardly a p5p matter any more] Quoth [EMAIL PROTECTED] (David Golden): On Tue, Sep 30, 2008 at 1:53 PM, Ben Morrow [EMAIL PROTECTED] wrote: I use it both for the declarative syntax and because it allows me to type /path/to/perl Makefile.PL make test in a dev directory with a fresh install of perl and get all the dependencies installed for me. Since I keep lots of versions of perl around and try to test my modules on all of them, this is highly convenient. Is that with auto-install? I guess I can see that purpose, though auto-install can be a real annoyance to end-users otherwise. Yes, it is. Auto-install can be useful to end users, of course, when installing something that isn't on CPAN but has CPAN dependancies; but the annoyance I can certainly see. Back before M::I played nicely with a running CPAN shell it used to be *incredibly* annoying, particularly on Win32. I'd probably do it this way with a recent version of CPAN.pm: $ /path/to/perl -MCPAN -e shell cpan test . I didn't know about that: thanks. Ben -- And if you wanna make sense / Whatcha looking at me for? (Fiona Apple) * [EMAIL PROTECTED] *
Re: Module::Install is a time bomb
On Tue, Sep 30, 2008 at 02:38:03PM -0400, David Golden wrote: On Tue, Sep 30, 2008 at 1:53 PM, Ben Morrow [EMAIL PROTECTED] wrote: I use it both for the declarative syntax and because it allows me to type /path/to/perl Makefile.PL make test in a dev directory with a fresh install of perl and get all the dependencies installed for me. Since I keep lots of versions of perl around and try to test my modules on all of them, this is highly convenient. Is that with auto-install? I guess I can see that purpose, though auto-install can be a real annoyance to end-users otherwise. I'd probably do it this way with a recent version of CPAN.pm: $ /path/to/perl -MCPAN -e shell cpan test . No Module::Install or auto-install required. That is f**king scary. -- Chris Williams aka BinGOs PGP ID 0x4658671F http://www.gumbynet.org.uk == pgppApL9Oiyzd.pgp Description: PGP signature
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
On Mon, Sep 29, 2008 at 11:07:47AM -0400, David Golden wrote: On Sun, Sep 28, 2008 at 9:54 PM, Adam Kennedy [EMAIL PROTECTED] wrote: As far as I'm concerned, configure_requires doesn't exist until there's prod release of both CPAN.pm and CPANPLUS that support it. Once there is, THEN we can draw a line under it, call it done, and start recommending the use of Module::Build again. FYI -- CPAN.pm supports configure_requires since 1.92. So we're only waiting on CPANPLUS. And then we just need to wait a few years for the world to upgrade. If the world upgraded regularly, Module::Build wouldn't be such a disaster anyway :) -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
Re: Module::Install is a time bomb
On Mon, Sep 29, 2008 at 01:59:09PM -0400, Michael G Schwern wrote: Matt S Trout wrote: use inc::Module::Install; I will say it again: Module::Install is the greatest threat to CPAN stability. Module::Install bundles itself, but will not use a newer installed version. [1] At some point something is going to happen which will break Module::Install. A subtle perl upgrade bug, some new operating system quirk, a dependency change, or more probably, MakeMaker will change something in its guts and one of the many hacks MI does will no longer work. You mean like how Module::Build broke over a YAML release and we spent over a year cleaning up after it because every single user who ran into that version mismatch had to have the problem explained to them? I still regularly see -ancient- versions of Module::Build installed lots of places, often pre-INSTALL_BASE-behaviour-change, which causes great fun when I upgrade it past that release. I know that's crap. I know it's sad. But it's the real world, and I live in it. At that point every dist which bundles MI will fail and we will have to wait while every one of them releases an update. From experience, this is a very, very slow process which will have repercussions for months and years after the initial OMGUBROKECPAN event. From experience, most actively maintained stuff fixes itself quite quickly. Anything that doesn't isn't actively maintained and is vulnerable to the same problem with every line of its own code as well. However, I think it's becoming fairly evident that to all intents and purposes we're arguing a matter of opinion here, so since I think we've now both stated our arguments pretty clearly I'm going to bow out of the thread at this point, and hope that if you agree with this paragraph, you'll agree to disagree on the rest of the points. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
Re: Module::Install is a time bomb
You mean like how Module::Build broke over a YAML release and we spent over a year cleaning up after it because every single user who ran into that version mismatch had to have the problem explained to them? I still regularly see -ancient- versions of Module::Build installed lots of places, often pre-INSTALL_BASE-behaviour-change, which causes great fun when I upgrade it past that release. I know that's crap. I know it's sad. But it's the real world, and I live in it. You guys are way beyond me when it comes to understanding this stuff. But as the average dodo, I really appreciate the real world attitude. I regularly have to deal with older perls supporting production installed software. I don't want to (or can't) upgrade it. I want the modules I use to work, especially the variety of work that involves not barfing when I try to install it. If autobundling (or whatever) solves that problem, then yay for that solution, as long as the amount of extra space involved isn't completely onerous. Essentially I agree with that f-word laden run on sentence you espoused earlier. Please to just be working. Austin
Re: Module::Install is a time bomb
On Tue, 30 Sep 2008 18:53:56 +0100, Ben Morrow [EMAIL PROTECTED] said: Personally, I wonder how many authors use it because of the bundling capability and how many use it for the simple declarative syntax for Makefile.PL. I use it both for the declarative syntax and because it allows me to type /path/to/perl Makefile.PL make test in a dev directory with a fresh install of perl and get all the dependencies installed for me. Since I keep lots of versions of perl around and try to test my modules on all of them, this is highly convenient. shamelessplug You should try /path/to/perl^Wcpan . # --- the last character is a dot instead. More than 22 strokes less to type and no shift key. Of course, if someone were to make all that work using M::B as the backend instead of EU::MM, I would be perfectly happy. Probably more so, as then extending M::I wouldn't require messing around with EU::MM's mess and the hacks required to make M::I work on top of that. cpan works with EUMM and MB and MI. /plug -- andreas
Re: Module::Install is a time bomb
# from Austin Schutz # on Tuesday 30 September 2008 16:54: I really appreciate the real world attitude. I regularly have to deal with older perls supporting production installed software. I don't want to (or can't) upgrade it. Is your it a) perl or b) CPAN.pm? If one is not allowed to upgrade one's perl modules, I think that one cannot be helped with the upgrading of one's perl modules. I want the modules I use to work, especially the variety of work that involves not barfing when I try to install it. It is unfortunate that any new module on the CPAN is assumed to be the latest and greatest and yet the 3-or-4-year-old installer is assumed to be ok because that's what the OS shipped with or whatever? cpan CPAN You can do that without needing to upgrade your perl. Then you have configure_requires support and henceforth any brand-new thing which happens to be required during installation of the brand-new thing you want will be conveniently installed for you. Of course it would be easier for you if we did that for you, but that has some complications so how's about you do it and tell your friends to do likewise? Thanks, Eric -- Matter will be damaged in direct proportion to its value. --Murphy's Constant --- http://scratchcomputing.com ---
Re: Module::Install is a time bomb
On Tue, Sep 30, 2008 at 6:04 PM, Gabor Szabo [EMAIL PROTECTED] wrote: BTW Could I somehow install all the dependencies of a module but not the module itself? make installdeps I believe this (for some reason) depends on using autoinstall which has its own problems. Shawn
Re: The problem with auto-installing dependencies
On Tue, Sep 30, 2008 at 12:12:22PM -0700, Bill Ward wrote: So I don't like auto-install. is someone stopping you from turning it off? are you aware of the prerequisites_policy for CPAN.pm, or whatever its analogue is for CPANPLUS? hdp.
RE: Module::Build 0.30 is released
Ken Williams wrote: Hi all, After much tireless work by Eric Wilhelm and lots of feedback from patient nonpatient users alike, I'm pleased to announce that version 0.30 of Module::Build is now on CPAN. This is the first non-beta release in a long time. Thanks, applied to bleadperl as 34446. Two local changes remain: Change 32357 by [EMAIL PROTECTED] on 2007/11/17 04:19:47 Skip Module::Build ppm test -- not ready for prime time on VMS. (ppm.t) Change 32351 by [EMAIL PROTECTED] on 2007/11/16 23:43:46 Silence ill-behaved or failing Module::Build tests on VMS. (test_type.t and xs.t parts only--the tilde.t part appears to have been superseded by code in 0.30. Please can you check that, Craig?) I've also just applied a new local change to fix compat.t, which was failing in my setup due to my having HARNESS_TIMER set to 1. I previously hacked around that in 33340, which was not taken up in 0.30, so hopefully this is better: Change 34447 by [EMAIL PROTECTED] on 2008/09/30 11:27:36 Fix Module-Build's compat.t when HARNESS_TIMER is set to 1 (compat.t)
Re: Module::Install is a time bomb
On Tue, Sep 30, 2008 at 06:53:56PM +0100, Ben Morrow wrote: Quoth [EMAIL PROTECTED] (David Golden): On Tue, Sep 30, 2008 at 10:23 AM, Johan Vromans [EMAIL PROTECTED] wrote: Michael G Schwern [EMAIL PROTECTED] writes: Module::Install is the greatest threat to CPAN stability. So why not get rid of it? If it does not provide any relevant functionality that EU::MM and M::B also provide, it should be possible to convince the author to withdraw it. Personally, I wonder how many authors use it because of the bundling capability and how many use it for the simple declarative syntax for Makefile.PL. I use it both for the declarative syntax and because it allows me to type /path/to/perl Makefile.PL make test in a dev directory with a fresh install of perl and get all the dependencies installed for me. Since I keep lots of versions of perl around and try to test my modules on all of them, this is highly convenient. Of course, if someone were to make all that work using M::B as the backend instead of EU::MM, I would be perfectly happy. Probably more so, as then extending M::I wouldn't require messing around with EU::MM's mess and the hacks required to make M::I work on top of that. Module::Install used to have a Module::Build backend but nobody cared enough to maintain it so it bit-rotted and eventually got deleted. I think Adam and I would both love to see it return if somebody was willing to give it sufficient love it worked properly again. -- Matt S Trout Need help with your Catalyst or DBIx::Class project? Technical Directorhttp://www.shadowcat.co.uk/catalyst/ Shadowcat Systems Ltd. Want a managed development or deployment platform? http://chainsawblues.vox.com/http://www.shadowcat.co.uk/servers/
Re: Module::Install is a time bomb
On Sep 30, 2008, at 5:04 PM, Gabor Szabo wrote: Excuse me? and you kept this information to yourself all those years? BTW Could I somehow install all the dependencies of a module but not the module itself? Yes, that's what the earlier test . recommendation meant. Personally, to get deps of darkpan code I usually do cpan . and then Ctrl-C when I hit the tests in ./t. Sloppy, but effective. Chris
Re: The problem with auto-installing dependencies
On Tue, Sep 30, 2008 at 3:18 PM, Hans Dieter Pearcey
[EMAIL PROTECTED] wrote:
On Tue, Sep 30, 2008 at 12:12:22PM -0700, Bill Ward wrote:
So I don't like auto-install.
is someone stopping you from turning it off?
are you aware of the prerequisites_policy for CPAN.pm, or whatever its
analogue
is for CPANPLUS?
That's not what he's talking about. He's talking about modules that
bundle Module::AutoInstall -- which runs CPAN.pm or CPANPLUS in a
subshell during make to install dependencies.
Newer versions of it look for $ENV{PERL5_CPANPLUS_IS_EXECUTING} and
$ENV{PERL5_CPAN_IS_EXECUTING} and defer to CPAN.pm or CPANPLUS to
handle prerequisites, but older versions that are bundled with some
modules thanks to Module::Install don't recognize those.
NB. And, of course, there was an intermediate version of
Module::AutoInstall that only looked for PERL5_CPANPLUS_IS_EXECUTING
and not the CPAN one, so more recent versions of CPAN.pm set both
environment variables to try to stop Module::AutoInstall from doing
its dirty work whenever possible.
-- David
Re: The problem with auto-installing dependencies
* David Golden [EMAIL PROTECTED] [2008-09-30T22:51:11] That's not what he's talking about. He's talking about modules that bundle Module::AutoInstall -- which runs CPAN.pm or CPANPLUS in a subshell during make to install dependencies. Are you sure? I think it's quite unclear. -- rjbs
