perl.module-authors

perl.module-authors http://www.nntp.perl.org/group/perl.module-authors/ ... Copyright 1998-2008 perl.org Tue, 07 Oct 2008 21:23:13 +0000 ask@perl.org Should CPAN install in the version dependent directory? by Johan Vromans I just did a % perl -MCPAN -e shell cpan> install Bundle::CPAN My config is to install in ~/lib/perl5. So now I have: lib/perl5/i386-linux-thread-multi/auto/Cwd/Cwd.so lib/perl5/i386-linux-thread-multi/auto/Digest/SHA/SHA.so ... etc ... I share my home between different Fedora systems, some running 5.8.8, others running 5.10.0. Since 5.8 is not binary compatible with 5.10 the .so files should be placed in lib/perl5/5.8.8/i386-linux-thread-multi/auto/Cwd/Cwd.so lib/perl5/5.8.8/i386-linux-thread-multi/auto/Digest/SHA/SHA.so Or am I overlooking something? -- Johan http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6959.html Mon, 06 Oct 2008 07:30:19 +0000 Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released) by Adam Kennedy I'll see to it that the pony goes into blead asap. Adam K 2008/10/4 Nicholas Clark <nick@ccl4.org>: > On Sat, Oct 04, 2008 at 01:55:50PM +1000, Adam Kennedy wrote: > >> The magic ponies will be introduced in 5.8.9 and 5.10.1. You indeed >> will never have to upgrade. > > 5.8.9 will ship, ponies ready or not. > > I don't see stable ponies in blead to merge. > > I'm not the only person who can commit to blead, so someone else can deal with > that part. > > Nicholas Clark > http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6958.html Sun, 05 Oct 2008 19:44:05 +0000 Re: Module::Build 0.30 is released by Craig A. Berry On Wed, Oct 1, 2008 at 1:13 PM, Craig A. Berry <craig.a.berry@gmail.com> wrote: > On Tue, Sep 30, 2008 at 6:33 AM, Steve Hay <SteveHay@planit.com> wrote: > >> Thanks, applied to bleadperl as 34446. >> >> Two local changes remain: >> >> Change 32357 by craigb@craigb-brianor on 2007/11/17 04:19:47 >> >> Skip Module::Build ppm test -- not ready for prime time on VMS. >> >> (ppm.t) This is a great deal closer to working than it was, but still not quite there yet. >> Change 32351 by craigb@craigb-brianor 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?) This was ok for now but we have more work to do upstream. I see these new failures after the integration of 0.30: lib/Module/Build/t/compat.....................................FAILED at test 13 lib/Module/Build/t/ext........................................FAILED at test 142 lib/Module/Build/t/tilde......................................FAILED at test 3 I think all of those were working last time I tried a CPAN version a few months ago but I obviously have not kept up on my testing. test_type.t and xs.t work fine individually but trigger a VMS-specific bug that causes the harness to see tests out of order. I think some output from a child process is bleeding through to the parent or something: $ perl test [-.lib.module.build.t]test_type.t lib/module/build/t/test_type....FAILED--expected test 5, saw test 4 Failed 1 test out of 1, 0.00% okay. [-.lib.module.build.t]test_type.t ### Since not all tests were successful, you may want to run some of ### them individually and examine any diagnostic messages they produce. ### See the INSTALL document's section on "make test". u=6.56 s=0.00 cu=0.00 cs=0.00 scripts=1 tests=9 %SYSTEM-F-ABORT, abort $ perl test [-.lib.module.build.t]xs.t lib/module/build/t/xs....FAILED--expected test 12, saw test 11 Failed 1 test out of 1, 0.00% okay. [-.lib.module.build.t]xs.t ### Since not all tests were successful, you may want to run some of ### them individually and examine any diagnostic messages they produce. ### See the INSTALL document's section on "make test". u=6.97 s=0.00 cu=0.00 cs=0.00 scripts=1 tests=23 %SYSTEM-F-ABORT, abort http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6957.html Sat, 04 Oct 2008 04:19:57 +0000 Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released) by Nicholas Clark On Sat, Oct 04, 2008 at 01:55:50PM +1000, Adam Kennedy wrote: > The magic ponies will be introduced in 5.8.9 and 5.10.1. You indeed > will never have to upgrade. 5.8.9 will ship, ponies ready or not. I don't see stable ponies in blead to merge. I'm not the only person who can commit to blead, so someone else can deal with that part. Nicholas Clark http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6956.html Sat, 04 Oct 2008 00:04:51 +0000 Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released) by Adam Kennedy 2008/10/3 Michael G Schwern <schwern@pobox.com>: >> 2008/9/30 Matt S Trout <matt-p5p@trout.me.uk>: >>> If the world upgraded regularly, Module::Build wouldn't be such a disaster >>> anyway :) > > Adam Kennedy wrote: >> True, but it's FAR more palatable to say "Just upgrade ONCE, and >> you'll never have to think about it again" compared to upgrading >> continuously. > > As long as we're talking platitudes, why don't we just say you never have to > upgrade! In fact, you never even have to install the software, magic ponies > inside your computer will just know when you need it and go get it for you. [1] The magic ponies will be introduced in 5.8.9 and 5.10.1. You indeed will never have to upgrade. Adam K http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6955.html Fri, 03 Oct 2008 20:56:00 +0000 Re: how can I building my own cpan server with old modules? by brian d foy In article <5d4beb40810030650tc2430adrd1fa25f0b3d0e0e0@mail.gmail.com>, David Golden <xdaveg@gmail.com> wrote: > On Fri, Oct 3, 2008 at 8:48 AM, Gabor Szabo <szabgab@gmail.com> wrote: > > Along the same lines I am not sure how difficult it would be to build > > a CPAN::Mini > > mirror that has the files as they were on any particular date in the past. > > > > So I would be able to say myminicpan --date 2006.06.27 > > and it would build a cpan mirror with all the files that were latest > > on CPAN on that day. > > Not terribly difficult as long as you know the logic for finding what > dists existed on date X and producing a list of distribution names. > (e.g. DAGOLDEN/Foo-Bar-1.23.tar.gz) All of that info is part of the information I'm collecting on each distribution, and one of my use cases is recreating CPAN at any particular time. The only information I don't have for that is when distributions were removed from CPAN. See, for instance: http://use.perl.org/~brian_d_foy/journal/37375 Take a look at those data files. Right now I'm just collecting the data, but once I do that, I'll start organizing it. If someone is really motivated, they could do that part for me. :) http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6954.html Fri, 03 Oct 2008 10:17:57 +0000 Re: how can I building my own cpan server with old modules? by Eric Wilhelm # from Gabor Szabo # on Friday 03 October 2008: >If there was such an easy solution in place, module-authors would need >to worry less >about supporting old versions of perl or old versions of the > toolchain. Users who are stuck with old toolchains or old perl could > just build an old version of >CPAN for themself. You may spend your time how you like, but I think the only case where users cannot upgrade the toolchain is with perls older than 5.6.x. For anything older, I recommend that you be getting paid for more than a 10-year support plan ;-) If you find a case where CPAN, CPANPLUS, Test::Harness, Test::More, or Module::Build don't work on a 5.6.x or later perl, please report it. --Eric -- "It works better if you plug it in!" --Sattinger's Law --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6953.html Fri, 03 Oct 2008 09:50:30 +0000 Re: how can I building my own cpan server with old modules? by David Golden On Fri, Oct 3, 2008 at 8:48 AM, Gabor Szabo <szabgab@gmail.com> wrote: > Along the same lines I am not sure how difficult it would be to build > a CPAN::Mini > mirror that has the files as they were on any particular date in the past. > > So I would be able to say myminicpan --date 2006.06.27 > and it would build a cpan mirror with all the files that were latest > on CPAN on that day. Not terribly difficult as long as you know the logic for finding what dists existed on date X and producing a list of distribution names. (e.g. DAGOLDEN/Foo-Bar-1.23.tar.gz) Look at the code for CPAN::Mini::Devel [1] -- it replaces the usual selection logic of CPAN::Mini to include latest devel versions. You want to do the same kind of thing and override _get_mirror_list(). The one tricky part I can anticipate is that BACKPAN doesn't have indices (and you need to create your own anyway) so you'll need to override mirror_indices() to do nothing and override _install_indices() to create the index files for your custom CPAN. [1] git://echo.dagolden.com/git/CPAN-Mini-Devel -- David http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6952.html Fri, 03 Oct 2008 06:50:20 +0000 Re: how can I building my own cpan server with old modules? by Gabor Szabo On Fri, Oct 3, 2008 at 1:40 PM, brian d foy <brian.d.foy@gmail.com> wrote: > In article > <d8a74af10810030002g612471d1k5a1142f5939c7018@mail.gmail.com>, Gabor > Szabo <szabgab@gmail.com> wrote: > > >> Now I need a button (I'll settle with a command line tool) >> that I can press and that will build my precious CPAN micro that >> contains exactly those two modules and the index. > > MyCPAN::Indexer can do that, which means it is set up to be able to > handle things like that but I haven't implemented this particular task. > > The latest MyCPAN stuff, which is my name for the BackPAN indexer, > is now pluggable. You can tell it how to get a list of modules to > process, how to process them, and how to write the report. If you look > in the git archive, check out the "test census" example. For that, I > have the indexer walk through distros, record the Test:: modules used, > and then write a summary. That's the same task you have, but you want > the modules in the dist (it finds that too) and a CPAN::Mini::Inject > for each one. > > I just demonstrated this at Chciago.pm and have the screencast on Vimeo > (and your exact use case came up too, but not while I was recording): > > http://vimeo.com/1808414 > > I have some other things on my plate right now, but I estimate this is > about two days of work for me. How fast do you need this? If it's > something that someone wants enough to pay some money, I could work on > it during work hours. Thanks, great. I hope I'll be able to to look at all those once I am back from my vacation. I personally don't need it right now. The question came to me as IMHO this can be a solution for all those people who cannot upgrade their toolchain. They might not be able to install the latest and greatest from CPAN as those might need some brand new features of MB or EUMM but they can go back in time, have a custom built CPAN frozen in ancient times just as they need it with juts enough of the old stuff they need. Along the same lines I am not sure how difficult it would be to build a CPAN::Mini mirror that has the files as they were on any particular date in the past. So I would be able to say myminicpan --date 2006.06.27 and it would build a cpan mirror with all the files that were latest on CPAN on that day. If there was such an easy solution in place, module-authors would need to worry less about supporting old versions of perl or old versions of the toolchain. Users who are stuck with old toolchains or old perl could just build an old version of CPAN for themself. >> Plus I'd like to >> get a report what else do I need with the possible version numbers. > > You mean dependencies? That's easy to get it you want to beleive > Makefile.PL or Build.PL, and slightly harder if you want the real > answer. Yes dependencies but it is not enough to know which module I need, I'd also like to know what version did I possibly use back when I installed this application. Gabor http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6951.html Fri, 03 Oct 2008 05:48:35 +0000 Re: how can I building my own cpan server with old modules? by brian d foy In article <d8a74af10810030002g612471d1k5a1142f5939c7018@mail.gmail.com>, Gabor Szabo <szabgab@gmail.com> wrote: > Now I need a button (I'll settle with a command line tool) > that I can press and that will build my precious CPAN micro that > contains exactly those two modules and the index. MyCPAN::Indexer can do that, which means it is set up to be able to handle things like that but I haven't implemented this particular task. The latest MyCPAN stuff, which is my name for the BackPAN indexer, is now pluggable. You can tell it how to get a list of modules to process, how to process them, and how to write the report. If you look in the git archive, check out the "test census" example. For that, I have the indexer walk through distros, record the Test:: modules used, and then write a summary. That's the same task you have, but you want the modules in the dist (it finds that too) and a CPAN::Mini::Inject for each one. I just demonstrated this at Chciago.pm and have the screencast on Vimeo (and your exact use case came up too, but not while I was recording): http://vimeo.com/1808414 I have some other things on my plate right now, but I estimate this is about two days of work for me. How fast do you need this? If it's something that someone wants enough to pay some money, I could work on it during work hours. > Plus I'd like to > get a report what else do I need with the possible version numbers. You mean dependencies? That's easy to get it you want to beleive Makefile.PL or Build.PL, and slightly harder if you want the real answer. http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6950.html Fri, 03 Oct 2008 03:40:23 +0000 Re: how can I building my own cpan server with old modules? by Gabor Szabo On Fri, Oct 3, 2008 at 4:36 AM, brian d foy <brian.d.foy@gmail.com> wrote: > In article > <d8a74af10810020617y104b2f8docc2814f0c9b61de6@mail.gmail.com>, Gabor > Szabo <szabgab@gmail.com> wrote: > > >> So how can I build such a CPAN mirror along with its index files? > > Which part of the process are you hung up on? I am looking for the button to press. :-) > > The only part that's a pain is getting the list of modules from a > distribution so you can feed it to CPAN::Mini::Inject. I haven't hooked > up my BackPAN indexing stuff to that yet, but all the technology is > there. > I can prepare a file with Module::Name 3.12 Another::Module 7.28 actually I already have the list in my Build.PL and Makefile.PL Now I need a button (I'll settle with a command line tool) that I can press and that will build my precious CPAN micro that contains exactly those two modules and the index. Plus I'd like to get a report what else do I need with the possible version numbers. Gabor who is supposed to be on vacation right now http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6949.html Fri, 03 Oct 2008 00:02:34 +0000 Re: overriding ~mumble~latest.pm by Eric Wilhelm # from Ricardo SIGNES # on Thursday 02 October 2008: >> That's not what latest.pm does.  The caller is expected to setup the >> @INC correctly for "use latest" -- *then* latest::import() figures >> out where the __THING YOU ACTUALLY WANT TO LOAD__ is. >> >> Is that clear?  Or, you could just read the code: > >That's what it would do if it was going to use a newer installed > version, which is what was being discussed. Until someone demonstrates a reason to put logic about which latest.pm is loaded in the latest.pm, I think we can skip discussing exactly what that logic should be. --Eric -- Those who cannot remember the past are condemned to repeat it. --George Santayana --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6948.html Thu, 02 Oct 2008 21:51:49 +0000 Re: overriding ~mumble~latest.pm by Ben Morrow Quoth scratchcomputing@gmail.com (Eric Wilhelm): > # from Ben Morrow > # on Thursday 02 October 2008: > > >Being able to install latest.pm[1] and use an installed version > > doesn't help, though. If there's a bug in the section of latest.pm > > that tries to locate the installed copy of itself and use it instead, > > you *still* can't fix it. And since that is the entire functionality > > of latest.pm, there won't ever be any bugs you can fix by installing > > a fixed version. > > That's not what latest.pm does. The caller is expected to setup the > @INC correctly for "use latest" -- *then* latest::import() figures out > where the __THING YOU ACTUALLY WANT TO LOAD__ is. I think we're in violent agreement here: maybe I wasn't clear enough. Ken said: latest.pm is never installed, the bundled version is used to locate the appropriate copy of M::B to use. Ricardo said: But what if there's a bug in the bundled version? Then we're back to repackaging everything just like with M::I. To avoid this latest.pm should defer to the installed version of itself if it's newer. I said: If there is a bug in latest.pm, being able to install a fixed copy doesn't help. If the bundled version were capable of correctly locating and deferring to the installed version, it could do the same for M::B. If it isn't, then you're screwed anyway. So: I understand that the plan is never to install latest.pm, and I think this is the only correct solution. Of course, latest.pm must be written rather carefully, and the temptation to add features must be resisted: this is bootstrap code only :). > There is nothing in the latest.pm which prevents it *itself* from being > superseded by an installed version I wonder if there should be? If we're running an installed copy of latest.pm instead of the bundled copy, then something has gone wrong; it may be better to let the user know they've done something stupid sooner rather than later. > >[1] IMHO it *really* ought to be called Module::Build::latest, as > >otherwise you're stomping on a top-level pragma namespace for the sake > >of a module that never gets installed. > > If it *were* designed to be installed, then: yes. I don't think it makes any difference. The namespace is still taken: if anyone ever had a latest.pm installed that did something different, *real* chaos would ensue :). Ben -- For far more marvellous is the truth than any artists of the past imagined! Why do the poets of the present not speak of it? What men are poets who can speak of Jupiter if he were like a man, but if he is an immense spinning sphere of methane and ammonia must be silent? [Feynmann] ben@morrow.me.uk http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6947.html Thu, 02 Oct 2008 20:18:11 +0000 Re: how can I building my own cpan server with old modules? by brian d foy In article <d8a74af10810020617y104b2f8docc2814f0c9b61de6@mail.gmail.com>, Gabor Szabo <szabgab@gmail.com> wrote: > So how can I build such a CPAN mirror along with its index files? Which part of the process are you hung up on? The only part that's a pain is getting the list of modules from a distribution so you can feed it to CPAN::Mini::Inject. I haven't hooked up my BackPAN indexing stuff to that yet, but all the technology is there. http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6946.html Thu, 02 Oct 2008 18:36:22 +0000 Re: overriding ~mumble~latest.pm by Ricardo SIGNES * Eric Wilhelm <scratchcomputing@gmail.com> [2008-10-02T20:18:46] > # from Ben Morrow > # on Thursday 02 October 2008: > > >Being able to install latest.pm[1] and use an installed version > > doesn't help, though. If there's a bug in the section of latest.pm > > that tries to locate the installed copy of itself and use it instead, > > you *still* can't fix it. And since that is the entire functionality > > of latest.pm, there won't ever be any bugs you can fix by installing > > a fixed version. > > That's not what latest.pm does. The caller is expected to setup the > @INC correctly for "use latest" -- *then* latest::import() figures out > where the __THING YOU ACTUALLY WANT TO LOAD__ is. > > Is that clear? Or, you could just read the code: That's what it would do if it was going to use a newer installed version, which is what was being discussed. There's no yell or imply that anyone is not paying attention. -- rjbs http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6945.html Thu, 02 Oct 2008 17:58:36 +0000 Re: overriding ~mumble~latest.pm by Eric Wilhelm # from Ben Morrow # on Thursday 02 October 2008: >Being able to install latest.pm[1] and use an installed version > doesn't help, though. If there's a bug in the section of latest.pm > that tries to locate the installed copy of itself and use it instead, > you *still* can't fix it. And since that is the entire functionality > of latest.pm, there won't ever be any bugs you can fix by installing > a fixed version. That's not what latest.pm does. The caller is expected to setup the @INC correctly for "use latest" -- *then* latest::import() figures out where the __THING YOU ACTUALLY WANT TO LOAD__ is. Is that clear? Or, you could just read the code: https://svn.perl.org/modules/Module-Build/trunk/inc/latest.pm There is nothing in the latest.pm which prevents it *itself* from being superseded by an installed version (or even has anything to do with itself for that matter), but "latest.pm" being installed *is not* the design as it currently stands. There *is* an issue with exactly what the author puts in their Build.PL, and I don't think that has been completely decided: 1. assume '.' is at the end of @INC: "use inc::latest 'Module::Build';" pro - overriding via installation now easy + only one line in Build.PL con - assumption might fail note: would require s/package latest/package inc::latest/ 2. BEGIN {unshift(@INC, 'inc')} aka "use lib 'inc'" pro - no assumptions: you know what you're getting con - harder to override note: but not impossible 3. BEGIN {push(@INC, 'inc')} pro - no assumptions + easy to override con - not pronounced "use lib 'inc'" And yes - #1 is what the Module::Install docs recommend. >[1] IMHO it *really* ought to be called Module::Build::latest, as >otherwise you're stomping on a top-level pragma namespace for the sake >of a module that never gets installed. If it *were* designed to be installed, then: yes. But granted that: 1. it only has meaning within a Build.PL and 2. we only need to override/install it on one really bad day Thus, I'm more inclined to treat it as a much smaller time bomb and simply plan to issue special emergency crowbars after the fact. --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6944.html Thu, 02 Oct 2008 17:19:07 +0000 Re: Module::Install is a time bomb by Ben Morrow Quoth perl.authors@rjbs.manxome.org (Ricardo SIGNES): > * Ken Williams <kenahoo@gmail.com> [2008-10-01T21:34:28] > > > > Ricardo: there's no such thing as "installed latest.pm". Please go > > back and read what I wrote above. > > I read and understood what you said. > > Perhaps I should've said, "presumably it would be better if..." > > This thread started with "Module::Install is a time bomb" because, in > large part, it bundles code that will not use later code found on the > installing system. Then when there is a bug, every author must > re-release a dist. That means that a fix to Module::Install means > that there must be a thousand more upgrades, one for each dist using > it. > > Module::Build is going to fix that by correctly using the latest > Module::Build -- either the one in ./inc or the one in @INC. It will > accomplish that by using code that is only found in the dist. That > means that when there is a bug, every author must re-release a dist. > That means that a fix to latest.pm means that there must be a thousand > more upgrades, one for each dist using it. > > I will admit that bugs in latest.pm (which I have not seen, but can > imagine) are less likely than bugs in Module::Install (which I have > seen, and wish I could not imagine). It still seems sort of bizarre > to have absolutely no nuclear option by which one can deal with 1,234 > deployed and broken latest.pms. Being able to install latest.pm[1] and use an installed version doesn't help, though. If there's a bug in the section of latest.pm that tries to locate the installed copy of itself and use it instead, you *still* can't fix it. And since that is the entire functionality of latest.pm, there won't ever be any bugs you can fix by installing a fixed version. [1] IMHO it *really* ought to be called Module::Build::latest, as otherwise you're stomping on a top-level pragma namespace for the sake of a module that never gets installed. Ben -- You poor take courage, you rich take care: The Earth was made a common treasury for everyone to share All things in common, all people one. 'We come in peace'---the order came to cut them down. [ben@morrow.me.uk] http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6943.html Thu, 02 Oct 2008 16:12:00 +0000 Re: How To Bundle Module::Build (was Re: Module::Build 0.30 isreleased) by Michael G Schwern Michael G Schwern wrote: >> 2008/9/30 Matt S Trout <matt-p5p@trout.me.uk>: >>> If the world upgraded regularly, Module::Build wouldn't be such a disaster >>> anyway :) > > Adam Kennedy wrote: >> True, but it's FAR more palatable to say "Just upgrade ONCE, and >> you'll never have to think about it again" compared to upgrading >> continuously. > > As long as we're talking platitudes, why don't we just say you never have to > upgrade! In fact, you never even have to install the software, magic ponies > inside your computer will just know when you need it and go get it for you. [1] > > Also everyone gets a million dollars and a pet dragon. Sorry, that was a first-thing-in-the-morning post. I've totally lost track of the thread. -- 191. Our Humvees cannot be assembled into a giant battle-robot. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/ http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6942.html Thu, 02 Oct 2008 09:50:08 +0000 Re: Other suggestions for modules that need an updated toolchain? (was latest.pm, Module::Build, etc.) by Ken Williams On Thu, Oct 2, 2008 at 11:23 AM, David Golden <xdaveg@gmail.com> wrote: > > Note -- I'm not saying *don't* do latest.pm and M::B bundling, as some > authors may prefer that -- I'm all in favor of M::B being everything > that people want and moving away from make as a Perl build tool. Absolutely - this is why I'm in full support of both latest.pm and configure_requires, so authors can choose whichever mechanism they happen to like. -Ken http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6941.html Thu, 02 Oct 2008 09:34:59 +0000 Re: Other suggestions for modules that need an updated toolchain? (was latest.pm, Module::Build, etc.) by David Golden On Thu, Oct 2, 2008 at 9:49 AM, Ken Williams <kenahoo@gmail.com> wrote: > That's not necessary when using latest.pm either. Unless latest.pm is buggy. Or unless a new Module::Build fixes some bug or changes some internal function that some distribution happened to depend upon. (Leaving aside the argument of the wisdom of using private functions.) From the author's perspective, they bundled a perfectly good Module::Build. But if latest.pm picks up a new one and things break, then it's re-release time anyway. latest.pm might minimize problems, but it doesn't eliminate them. I'm suggesting avoiding bundling and just saying "this module has dependencies and it's the user's responsibility to satisfy them to make it work". There's a bootstrap problem in that configure-time dependencies need to be resolved and we have tools that do that. If someone doesn't like CPAN{PLUS}, then it's still their responsibility to resolve well-specified dependencies. I just don't want to see band-aids on band-aids if we can avoid it. I say this based on my work on CPAN::Reporter writing heuristics to detect the various failure modes of the various band-aids in the wild on CPAN.pm. Note -- I'm not saying *don't* do latest.pm and M::B bundling, as some authors may prefer that -- I'm all in favor of M::B being everything that people want and moving away from make as a Perl build tool. Instead, I'm asking about alternatives for those who prefer to avoid bundling. -- David http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6940.html Thu, 02 Oct 2008 09:23:58 +0000 Re: How To Bundle Module::Build (was Re: Module::Build 0.30 isreleased) by Michael G Schwern > 2008/9/30 Matt S Trout <matt-p5p@trout.me.uk>: >> If the world upgraded regularly, Module::Build wouldn't be such a disaster >> anyway :) Adam Kennedy wrote: > True, but it's FAR more palatable to say "Just upgrade ONCE, and > you'll never have to think about it again" compared to upgrading > continuously. As long as we're talking platitudes, why don't we just say you never have to upgrade! In fact, you never even have to install the software, magic ponies inside your computer will just know when you need it and go get it for you. [1] Also everyone gets a million dollars and a pet dragon. [1] I anticipate the Acme::Magic::Pony auto-installer on CPAN by Monday. -- 'All anyone gets in a mirror is themselves,' she said. 'But what you gets in a good gumbo is everything.' -- "Witches Abroad" by Terry Prachett http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6939.html Thu, 02 Oct 2008 08:04:57 +0000 Re: Other suggestions for modules that need an updated toolchain? (was latest.pm, Module::Build, etc.) by Ken Williams On Thu, Oct 2, 2008 at 8:01 AM, David Golden <xdaveg@gmail.com> wrote: > As some have noted, CPAN.pm supports "configure_requires" and CPANPLUS > will soon, so to me it seems like the a better problem to address is > how to get an end-user to upgrade those. Not everyone likes to use CPAN{PLUS} to install modules, though. > If I also put Module::Build 0.30 in configure_requires, then anyone > with a CPAN or CPANPLUS that supports configure_requires will never > see the message because M::B 0.30 or better would be installed before > Build.PL runs. I'd put this at the top of my Build.PL file. I think > it would also work at the top of a "small" style Makefile.PL created > with Module::Build::Compat. (I.e. the one that passes everything > through to Build.PL, but doesn't try to install M::B.) That's true, but there are some people who (quite loudly) don't like the "small" style Makefile.PLs, because they impersonate an EU::MM setup without actually being one. Note also that the latest.pm approach can just as easily load a bundled EU::MM distribution. > > That seems like a lot less work and maintenance headache to me as an > author. It avoids me having to re-release my distribution when M::B > is updated to fix bugs. That's not necessary when using latest.pm either. -Ken http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6938.html Thu, 02 Oct 2008 06:49:13 +0000 how can I building my own cpan server with old modules? by Gabor Szabo I don't want the latest and breakest of CPAN. Assuming I have a list of modules with the appropriate *old* version numbers that I know my application is working with. I would like to be able to point my *old* CPAN.pm to a CPAN mirror that carries exactly those modules with exactly those versions. So how can I build such a CPAN mirror along with its index files? regards Gabor http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6937.html Thu, 02 Oct 2008 06:17:56 +0000 Other suggestions for modules that need an updated toolchain? (was latest.pm, Module::Build, etc.) by David Golden I've been following the threads here and on p5p about autobundling for Module::Build, using latest.pm etc., and I have to say that the I find the growing complexity required to be backward compatible a bit disturbing. As some have noted, CPAN.pm supports "configure_requires" and CPANPLUS will soon, so to me it seems like the a better problem to address is how to get an end-user to upgrade those. My first inclination as a module author is something along these lines: eval "use Module::Build 0.30" or die << UPGRADE Installing this module requires an updated CPAN toolchain. Please install either Bundle::CPAN or Bundle::CPANPLUS as appropriate. UPGRADE If I also put Module::Build 0.30 in configure_requires, then anyone with a CPAN or CPANPLUS that supports configure_requires will never see the message because M::B 0.30 or better would be installed before Build.PL runs. I'd put this at the top of my Build.PL file. I think it would also work at the top of a "small" style Makefile.PL created with Module::Build::Compat. (I.e. the one that passes everything through to Build.PL, but doesn't try to install M::B.) That seems like a lot less work and maintenance headache to me as an author. It avoids me having to re-release my distribution when M::B is updated to fix bugs. What do people think? And what other suggestions do people have for ways to encourage toolchain upgrades? -- David http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6936.html Thu, 02 Oct 2008 06:01:34 +0000 Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released) by Adam Kennedy True, but it's FAR more palatable to say "Just upgrade ONCE, and you'll never have to think about it again" compared to upgrading continuously. Adam K 2008/9/30 Matt S Trout <matt-p5p@trout.me.uk>: > If the world upgraded regularly, Module::Build wouldn't be such a disaster > anyway :) http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6935.html Thu, 02 Oct 2008 04:22:05 +0000 Re: Module::Build 0.30 is released by Craig A. Berry On Tue, Sep 30, 2008 at 6:33 AM, Steve Hay <SteveHay@planit.com> wrote: > Thanks, applied to bleadperl as 34446. > > Two local changes remain: > > Change 32357 by craigb@craigb-brianor on 2007/11/17 04:19:47 > > Skip Module::Build ppm test -- not ready for prime time on VMS. > > (ppm.t) > > Change 32351 by craigb@craigb-brianor 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'll look into it. I think those were band-aids to expedite getting 5.10.0 out the door and what's coming from upstream now will fix at least some of the problems we had then. http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6934.html Thu, 02 Oct 2008 02:06:45 +0000 RE: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch. by Steve Hay John E. Malmberg wrote: > Jos I. Boumans wrote: >> Hi John, >> >> On Oct 1, 2008, at 2:51 AM, John E. Malmberg wrote: >> >>> >>> http://www.nntp.perl.org/group/perl.vmsperl/2008/06/msg14821.html >>> >>> The main problem is that Archive::Tar needs a patch to properly be >>> able to pack a VMS binary into a tarball. >>> >>> We were waiting for word from Jos on this. >> >> It was my understanding that this was already applied to core, and >> it's also part of Archive::Tar 1.39_01: > > I just verified that the fix is not in blead perl as of today's rsync > copy just now. > > To be more specific it is a patch to Archive/Tar/File.pm to fix > handling of VMS binary executable files. It also fixes setting the > UID properly when saving the UID is requested. > >> http://search.cpan.org/src/KANE/Archive-Tar-1.39_04/CHANGES > > Yes I see that the patch is in the changelog. > >> A::T 1.39_04 looks stable, so we can promote it to 1.40 shortly. >> >> Is there anything specific you need me to do now? > > It looks like we need for blead to get more up to date. Blead is now updated to Archive-Tar-1.39_04 in #34452. One local change remains in blead: Change 32352 by craigb@craigb-brianor on 2007/11/16 23:46:13 The new Archive::Tar tests are TODO on VMS for reasons unrelated to the security issue for which they are testing. and I've just made another local change to fix a test that was failing after the upgrade: Change 34453 by steveh@maldoror on 2008/10/01 16:55:42 Fix Archive-Tar's 02_methods.t when IO::Compress::Bzip2 is absent (We haven't got IO::Compress::Bzip2 in blead, and can_handle_compressed_files() checks for both IO::Zlib and IO::Compress::Bzip2, which caused test 1 to fail without this change. Hmm... Thinking some more (sadly *after* I just hit "submit", perhaps it would have been better to change test 1 to check against $ZLIB && $BZIP, rather than changing the meaning of $ZLIB?) http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6933.html Thu, 02 Oct 2008 01:33:16 +0000 Re: Module::Build 0.30 is released - ppm.t on VMS depends on Archive::Tar patch. by Craig A. Berry On Wed, Oct 1, 2008 at 12:00 PM, Steve Hay <SteveHay@planit.com> wrote: > Blead is now updated to Archive-Tar-1.39_04 in #34452. > > One local change remains in blead: > > Change 32352 by craigb@craigb-brianor on 2007/11/16 23:46:13 > > The new Archive::Tar tests are TODO on VMS for reasons unrelated > to the security issue for which they are testing. Well, that's a desperate-sounding and evasive commit message if I've ever seen one. And the evidence suggests I have seen this one. I'll take a look and see if the evasion is still necessary. http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6932.html Thu, 02 Oct 2008 01:14:04 +0000 Re: Module::Build 0.30 is released - ppm.t on VMS depends onArchive::Tar patch. by John E. Malmberg Jos I. Boumans wrote: > Hi John, > > On Oct 1, 2008, at 2:51 AM, John E. Malmberg wrote: > >> >> http://www.nntp.perl.org/group/perl.vmsperl/2008/06/msg14821.html >> >> The main problem is that Archive::Tar needs a patch to properly be >> able to pack a VMS binary into a tarball. >> >> We were waiting for word from Jos on this. > > It was my understanding that this was already applied to core, and > it's also part of Archive::Tar 1.39_01: I just verified that the fix is not in blead perl as of today's rsync copy just now. To be more specific it is a patch to Archive/Tar/File.pm to fix handling of VMS binary executable files. It also fixes setting the UID properly when saving the UID is requested. > http://search.cpan.org/src/KANE/Archive-Tar-1.39_04/CHANGES Yes I see that the patch is in the changelog. > A::T 1.39_04 looks stable, so we can promote it to 1.40 shortly. > > Is there anything specific you need me to do now? It looks like we need for blead to get more up to date. I also need to find the time to get the fix into gnu tar, because it is also mis-handling the VMS file sizes for executable binaries. Gnu tar also needs a fix for handling VMS GID values on creating an archive, which I also noticed when debugging this issue. As it is right now, A::T 1.39_04 is probably the only way to build a tarball on VMS that includes an executable binary. -John wb8tyw@qsl.net Personal Opinion Only http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6931.html Thu, 02 Oct 2008 01:13:27 +0000 Re: latest.pm by Eric Wilhelm # from Ricardo SIGNES # on Wednesday 01 October 2008: >I will admit that bugs in latest.pm (which I have not seen, but can > imagine) are less likely than bugs in Module::Install (which I have > seen, and wish I could not imagine). Please see the run-down of usage, and link to sample distribution: http://www.nntp.perl.org/group/perl.module.build/2008/09/msg1665.html > It still seems sort of bizarre > to have absolutely no nuclear option by which one can deal with 1,234 > deployed and broken latest.pms. Please see the -M switch and some code like: unshift(@INC, \&fix_the_problem); The fact that latest.pm is very small makes it rather unlikely to be needed and potentially an easy fix if it is needed. One could probably apply that argument to Module::Install too, except for the small bit. --Eric -- Peer's Law: The solution to the problem changes the problem. --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6930.html Wed, 01 Oct 2008 22:15:01 +0000 Re: The problem with auto-installing dependencies by Dave Rolsky On Thu, 2 Oct 2008, Aristotle Pagaltzis wrote: > * Dave Rolsky <autarch@urth.org> [2008-10-01 17:05]: >> Installation and dependency chains are an issue best solved in >> the context of _applications_. > > That just moves the problem, though: an that uses modules with > lots of dependencies will demand more build engineering effort. Yes, my point is that it moves the problem to the people who are in the best position to deal with it. The whole "dependency problem" isn't a problem for module _authors_ like us. If we want to depend on stuff, we install it from CPAN, develop the new module, and release. It's a problem if you have an application that needs to be installed in a system with some sort of constraint. That constraint could be that the app plays well with other apps, that modules can't be upgraded, that all code on the system needs review by someone, etc. The application is also the place where you can come up with multiple solutions, like system packages, install in /opt, custom lib dir, PAR, etc. -dave /*========================== VegGuide.Org Your guide to all that's veg ==========================*/ http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6929.html Wed, 01 Oct 2008 21:00:31 +0000 Re: Module::Install is a time bomb by Aristotle Pagaltzis * Ken Williams <kenahoo@gmail.com> [2008-10-02 04:10]: > It's only executed as part of the build system, not ever > installed. In this respect it's just like any code that's in > the Build.PL or t/*.t. But those are written and maintained by the author. Wouldn’t it make more sense to make latest.pm part of Module::Build proper? Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6928.html Wed, 01 Oct 2008 20:47:03 +0000 Re: The problem with auto-installing dependencies by Aristotle Pagaltzis * Dave Rolsky <autarch@urth.org> [2008-10-01 17:05]: > Installation and dependency chains are an issue best solved in > the context of _applications_. That just moves the problem, though: an that uses modules with lots of dependencies will demand more build engineering effort. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/> http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6927.html Wed, 01 Oct 2008 20:35:12 +0000 Re: Module::Install is a time bomb by Ricardo SIGNES * Ken Williams <kenahoo@gmail.com> [2008-10-01T21:34:28] > On Wed, Oct 1, 2008 at 12:02 PM, Ricardo SIGNES > >> latest.pm doesn't ever get installed on anyone's computer. If you > >> install it, we have a backup plan for that too - the guys in black > >> coats will come and take your computer away. > > > > Well, at this point we're back to "everybody must upgrade everything." > > Presumably latest.pm knows to use the installed latest.pm if it's later, > > even if this is rarely true and even more rarely needed. > > Ricardo: there's no such thing as "installed latest.pm". Please go > back and read what I wrote above. I read and understood what you said. Perhaps I should've said, "presumably it would be better if..." This thread started with "Module::Install is a time bomb" because, in large part, it bundles code that will not use later code found on the installing system. Then when there is a bug, every author must re-release a dist. That means that a fix to Module::Install means that there must be a thousand more upgrades, one for each dist using it. Module::Build is going to fix that by correctly using the latest Module::Build -- either the one in ./inc or the one in @INC. It will accomplish that by using code that is only found in the dist. That means that when there is a bug, every author must re-release a dist. That means that a fix to latest.pm means that there must be a thousand more upgrades, one for each dist using it. I will admit that bugs in latest.pm (which I have not seen, but can imagine) are less likely than bugs in Module::Install (which I have seen, and wish I could not imagine). It still seems sort of bizarre to have absolutely no nuclear option by which one can deal with 1,234 deployed and broken latest.pms. -- rjbs http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6926.html Wed, 01 Oct 2008 20:26:26 +0000 Re: latest.pm usage by Ken Williams On Wed, Oct 1, 2008 at 12:34 PM, Eric Wilhelm <scratchcomputing@gmail.com> wrote: > # from Ken Williams >> use latest 'Module::Build'; # Knows to look in inc/bundled/ > > Um, isn't that 'inc/inc_*', or did I miss a memo? Yeah, latest.pm is currently looking in any inc/inc_* for bundled stuff, but that strikes me as kind of dumb actually. I don't know why I used "_" as a namespace separator when the filesystem already has a perfectly good "/" (and the like). -Ken http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6925.html Wed, 01 Oct 2008 19:14:00 +0000 Re: Module::Install is a time bomb by Ken Williams On Wed, Oct 1, 2008 at 8:38 PM, David Golden <xdaveg@gmail.com> wrote: > If I understand correctly, latest.pm isn't a module on CPAN, thus is > never installed only bundled. > > I.e. It's not only::latest (http://search.cpan.org/dist/only-latest) > > Correct? Correct. It's only executed as part of the build system, not ever installed. In this respect it's just like any code that's in the Build.PL or t/*.t. -Ken http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6924.html Wed, 01 Oct 2008 19:07:10 +0000 Re: Module::Install is a time bomb by David Golden On Wed, Oct 1, 2008 at 9:34 PM, Ken Williams <kenahoo@gmail.com> wrote: > Ricardo: there's no such thing as "installed latest.pm". Please go > back and read what I wrote above. If I understand correctly, latest.pm isn't a module on CPAN, thus is never installed only bundled. I.e. It's not only::latest (http://search.cpan.org/dist/only-latest) Correct? -- David http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6923.html Wed, 01 Oct 2008 18:38:24 +0000 Re: Module::Install is a time bomb by Ken Williams On Wed, Oct 1, 2008 at 12:02 PM, Ricardo SIGNES <perl.authors@rjbs.manxome.org> wrote: > * Ken Williams <kenahoo@gmail.com> [2008-10-01T12:15:04] >> On Wed, Oct 1, 2008 at 11:12 AM, Smylers <Smylers@stripey.com> wrote: >> > But what if the bundled version of latest.pm is buggy and I already have >> > a later latest.pm installed on my system? That will use the wrong one!! >> >> latest.pm doesn't ever get installed on anyone's computer. If you >> install it, we have a backup plan for that too - the guys in black >> coats will come and take your computer away. > > Well, at this point we're back to "everybody must upgrade everything." > Presumably latest.pm knows to use the installed latest.pm if it's later, even > if this is rarely true and even more rarely needed. Ricardo: there's no such thing as "installed latest.pm". Please go back and read what I wrote above. -Ken http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6922.html Wed, 01 Oct 2008 18:34:36 +0000 Re: latest.pm usage by Eric Wilhelm # from Ken Williams # on Wednesday 01 October 2008: >The semantics we're working on for people to use are: > > use lib 'inc'; # Where latest.pm lives > use latest 'Module::Build';  # Knows to look in inc/bundled/ Um, isn't that 'inc/inc_*', or did I miss a memo? --Eric -- Moving pianos is dangerous. Moving pianos are dangerous. Buffalo buffalo buffalo buffalo buffalo buffalo buffalo. --------------------------------------------------- http://scratchcomputing.com --------------------------------------------------- http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6921.html Wed, 01 Oct 2008 10:35:11 +0000 Re: Module::Install is a time bomb by Ricardo SIGNES * Ken Williams <kenahoo@gmail.com> [2008-10-01T12:15:04] > On Wed, Oct 1, 2008 at 11:12 AM, Smylers <Smylers@stripey.com> wrote: > > But what if the bundled version of latest.pm is buggy and I already have > > a later latest.pm installed on my system? That will use the wrong one!! > > latest.pm doesn't ever get installed on anyone's computer. If you > install it, we have a backup plan for that too - the guys in black > coats will come and take your computer away. Well, at this point we're back to "everybody must upgrade everything." Presumably latest.pm knows to use the installed latest.pm if it's later, even if this is rarely true and even more rarely needed. -- rjbs http://www.nntp.perl.org/group/perl.module-authors/2008/10/msg6920.html Wed, 01 Oct 2008 10:02:17 +0000