Re: inc/latest.pm
# from Ken Williams # on Sunday 28 September 2008: >We're not limited to using it for M::B, we've already got the start of >a general-purpose bundled-dist loader, check out inc/latest.pm . Where is the documentation and/or tests? Is it remotely ready to roll? What's the basic procedure for using it? Should a dummy distribution using it be sent to CPAN for the testers? From my reading, the tricky part is checking whether it works for bundling something besides Module::Build. Perhaps something in xt/ which doesn't have to be so constrained about environment assumptions could at least allow us to make sure we don't break it for some set of use cases? --Eric -- I eat your socks and you pay me. --The business sense of a very small goat. --- http://scratchcomputing.com ---
Re: inc/latest.pm
# from Eric Wilhelm # on Monday 29 September 2008: ># from Ken Williams >>We're not limited to using it for M::B, we've already got the start >> of a general-purpose bundled-dist loader, check out inc/latest.pm . > >Where is the documentation and/or tests? Is it remotely ready to > roll? What's the basic procedure for using it? As of right now: svn co https://svn.perl.org/modules/Module-Build/trunk \ /path/to/Module-Build/ cd /path/to/your-dist perl /path/to/Module-Build/scripts/bundle.pl And then start your Build.PL with: use lib 'inc'; use latest 'Module::Build'; >Should a dummy distribution using it be sent to CPAN for the testers? Anybody want to try it? http://scratchcomputing.com/tmp/CPTDP5BB-v0.0.1.tar.gz That's a CPAN-Test-Dummy-Perl5-Build-Bundled, based on what Andreas already has used for dummy namespaces. If he wants to put it up or doesn't mind the name, or whatever. >From my reading, the tricky part is checking whether it works for >bundling something besides Module::Build. And this also doesn't provide `./Build dist --bundled` or something, which is a different thing than when you just have a checkout or unpacked tarball. To do that, we would need to stick the latest.pm somewhere in the install tree and probably just copy all of the .pm files from the packlist, prepend to the Build.PL, MANIFEST, etc. --Eric -- "...the bourgeoisie were hated from both ends: by the proles, because they had all the money, and by the intelligentsia, because of their tendency to spend it on lawn ornaments." --Neal Stephenson --- http://scratchcomputing.com ---
Re: local @INC in inc/latest.pm
# from [EMAIL PROTECTED] # on Monday 29 September 2008: > # Only bundled is available >- local @INC = ($bundled_dir, @INC); >+ unshift(@INC, $bundled_dir); >... > # Load the bundled copy >- local @INC = ($bundled_dir, @INC); >+ unshift(@INC, $bundled_dir); Ken, what was the reasoning behind the 'local @INC' here? I was getting 'originally created with' troubles and I don't think the 'inc/inc_Module-Build' dir was carrying through to the "./Build". Was the plan to have ./Build contain a "use lib 'inc'; use latest ..." line? And if so: would that not also result in subprocesses missing it? That is, I think we need to use the PERL5LIB mechanism[1] for the inc/inc_* stuff. [1] well, whatever the current PERL5LIB mechanism becomes when we come up with to deal with the exploding PERL5LIB thing. --Eric -- The opinions expressed in this e-mail were randomly generated by the computer and do not necessarily reflect the views of its owner. --Management --- http://scratchcomputing.com ---
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
2008/9/29 Michael G Schwern <[EMAIL PROTECTED]>:
> Rather than a brute force "bundle your dependencies" there is now
> configure_requires. You can set configure_requires => { 'Module::Build' =>
> X.YY } in your Build.PL and an up-to-date CPAN shell will do the right thing.
> We've pressed hard to make sure all the build tools honor configure_requires.
> The CPAN shell has done it for a year now. CPANPLUS is still working on
> getting a stable release out, so if you want to help, help with that.
> Otherwise I don't want to hear about it.
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.
Adam K
Re: inc/latest.pm
On Mon, Sep 29, 2008 at 2:39 AM, Eric Wilhelm <[EMAIL PROTECTED]> wrote: > From my reading, the tricky part is checking whether it works for > bundling something besides Module::Build. This method of bundling is really only for build-time dependencies, of course. Which means it should be good for Test::* and friends too. -Ken
Re: Module::Build 0.30 is released
On Sunday 28 September 2008 06:38:44 Matt S Trout wrote: > Never mind, I'll go back to waiting for it to be five years from now and > the toolchain to have worked round this brain damage. That's not helpful. When a project doesn't release a new version, some people say "Oh, don't use it! They don't release new versions!" When a project does release a new version, some people say "Oh, don't use it! It's not perfect yet!" Meanwhile, the so-called reliable state of the art is a jumble of Perl which writes cross platform shell scripts to install Perl code, and you customize that by writing a superclass from which platform-specific modules inherit pseudo-methods which use regular expressions to search and replace cross-platform cross-shell code, with all of the cross-platform and cross-shell quoting issues that entails. I wish I were making any of this up. (I wrote tests for part of it.) This is why we can't have nice things. -- c
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
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. -- David
Re: object accessors have been getting invoked as $class->foo()
On Sep 28, 2008, at 08:25, David E. Wheeler wrote: As for the rest of your patch David, would you mind porting it forward to fit this refactor? I think the API you'll want is basically like: _make_accessor($property, %opts). Yes, I'll do that, but I'm less inclined to contribute in the future if you force me to rewrite my patches because you discover, thanks to my patch, that you don't like the current code, so you change it and force me to rewrite. Please, if you're going to do that, wait until my code is committed so that there's less work to be done overall. Eric, are you going to commit your patch so I can finish re-doing my and resubmitting it? Also, have we settled on 4- or 2- space indents yet? At this point, though I prefer 4-space, I don't really care enough to press it, as long as tabs go away. Thanks, David
Module::Install is a time bomb
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. 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. This breaks the "move to the latest version" way that CPAN normally defends against this sort of problem. In addition, because each bundled copy of MI might have been custom hacked by the author, a user can't even do a manual upgrade. 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. [1] Yes, it does this for reasons. -- You are wicked and wrong to have broken inside and peeked at the implementation and then relied upon it. -- tchrist in <[EMAIL PROTECTED]>
Re: [RFC] Dealing with World-writable Files in the Archive of CPAN Distributions
> On Tue, 23 Sep 2008 11:40:09 +0200, "Jos I. Boumans" <[EMAIL PROTECTED]> > said: >> And so I have implemented it now. If it breaks too much in too short >> time, we could probably revert it, but first I'd like to see how bad >> we really do. > I agree to this (first) solution; this will give us a good idea about > the > scope of the problem. I have watched the indexer for a week now. The scope is more than two uploads per day. These uploads got an email about world writable files or directories. I looked up their CPAN directories right now and based on the findings I have added the third column. 23-Sep SEMUELF/Data-ParseBinary-0.07.tar.gzfixed 26-Sep GFUJI/warnings-unused-0.02.tar.gz not fixed 26-Sep STEFFENW/DBD-PO-0.10.tar.gz not fixed 26-Sep STEFFENW/Bundle-DBD-PO-0.10.tar.gz not fixed 26-Sep AJDIXON/daemonise-1.0.tar.gznot fixed 26-Sep RPHANEY/openStatisticalServices-0.015.tar.gzfixed 26-Sep RPHANEY/openStatisticalServices-0.018.tar.gzfixed 27-Sep COSIMO/Imager-SkinDetector-0.01.tar.gz fixed 27-Sep FAYLAND/Pod-From-GoogleWiki-0.06.tar.gz fixed 28-Sep DANNY/Rose-DBx-Object-Renderer-0.34.tar.gz not fixed 28-Sep MTHURN/WWW-Search-Ebay-2.244.tar.gz fixed 28-Sep JSTROM/Tk-TextVi-0.014.tar.gz not fixed 28-Sep JSTROM/Tk-TextVi-0.0141.tar.gz not fixed 29-Sep MATTN/Net-Kotonoha-0.07.tar.gz fixed 29-Sep MTHURN/WWW-Search-Ebay-Europe-2.002.tar.gz fixed 29-Sep ANGERSTEI/Net-Ping-Network-1.57.tar.gz not fixed 29-Sep RPHANEY/openStatisticalServices-0.019.tar.gzfixed Congratulations to all authors who managed to fix their distros. I *you* are among them, please spread the word how you did it. I expect that the third column is already wrong when you read this. Good night, -- andreas
Re: How To Bundle Module::Build (was Re: Module::Build 0.30 is released)
On Sun, Sep 28, 2008 at 04:16:33PM -0400, Michael G Schwern wrote: > Matt, I've met a lot of people who don't use Module::Build because you said > not to use it. They usually don't know why. There's already enough FUD > flying around without adding to it. Please either give us specifics we can > fix or stop it with the FUD. The specific is, and always has been, lack of autobundling which results in people having random releases. DBIx::Class doesn't have this issue because people can specify it in their Build/Makefile.PL and CPAN can handle it. Until configure_requires is widely deployed, say a couple years from now, that simply isn't the case for Build/Makefile.PL-time dependencies so autobundling is the sane workaround. As soon as Ken cuts a release with autobundling, I'll switch from "don't use it" to "if you use it, make sure you turn on autobundling unless you're damn sure all your users have configure_requires support". In the meantime, using Module::Build contravenes the "just fucking make it fucking easy to fucking install" rule which is why I recommend against it. Anyway, Ken's already given a perfectly logical reason for why autobundling isn't in this release and a statement that it will turn up soon, so this conversation is going to be moot very shortly anyway, happily. Again, KWILLIAMS++ > If you still insist on bundling Module::Build, you don't need Module::Build to > help you with that. Just do this: > > There, you have your bundling and a fuckton easier than in MakeMaker. use inc::Module::Install; is so much easier though. But hopefully the M::B bundling system will be just as easy, and then people can just use whichever they prefer. Me, I'm an old-school unix head and -like- Makefiles so I'll probably stick with M::I anyway at this point, but I'll make very clear at that point that that's a matter of taste on my part. -- 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::Build 0.30 is released
On Sun, Sep 28, 2008 at 11:33:09AM -0500, Ken Williams wrote: > On Sun, Sep 28, 2008 at 8:38 AM, Matt S Trout <[EMAIL PROTECTED]> wrote: > > I was told it was a planned feature when KWILLIAMS turned up on london.pm > > and yelled "FUD" because I was complaining about users' problems in the > > real world rather than the problems of an ideal user that somehow magically > > knows that Module::Build is special and they have to remember to update it > > or installations will inexplicably fail. > > Can you show us that thread or a specific bug? The london.pm archive is searchable; I was complaining about now-fixed bugs that were still in the wild anyway - a response of "these are now fixed but it -is- a shame there's no easy way to force an update" would have been fine, I only took exception to having "FUD" yelled at me when I still encounter these problems regularly when supporting clients and OOS users. > Autobundling of M::B is indeed a planned feature. It's my personal > top priority. But we wanted to get "all the rest" of the work that's > been done in the last 1.5 years out the door before tackling it. And > autobundling is a nice special kind of feature that specifically > doesn't have to be tied to a major release schedule, so as long as we > get it out the door in a small amount of calendar time, people should > be happy. That's absolutely and perfectly logical, and I look forward to seeing it on CPAN. KWILLIAMS++ -- 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
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'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. Because it requires manual intervention to fix, even if it only has to be fixed once per install, and we don't like that. -- 39. Not allowed to ask for the day off due to religious purposes, on the basis that the world is going to end, more than once. -- The 213 Things Skippy Is No Longer Allowed To Do In The U.S. Army http://skippyslist.com/list/
