Skip Menu |

This queue is for tickets about the Module-Build CPAN distribution.

Report information
The Basics
Id: 62495
Status: open
Priority: 0/
Queue: Module-Build

People
Owner: Nobody in particular
Requestors: thaljef [...] cpan.org
Cc:
AdminCc:

Bug Information
Severity: Wishlist
Broken in: (no value)
Fixed in: 0.3603



Subject: Feature request: New "distinstall" target
Hi there- My team develops and maintains several Perl modules in CPAN-style distributions, and we absolutely love Module::Build. In the typical development cycle, it is pretty common to run "./Build install" from the checkout directory. But this has become problematic. We use the new share_dir option to manage our non-code resources, which tends to clutter the blib/ directory with .svn files and other junk. And when you run "./Build install" from the checkout directory, all that junk gets installed in /usr/local/lib/perl5 (or wherever). But if we run "./Build install" in the distdir, then everything works beautifully, because the MANIFEST.SKIP makes sure that distdir doesn't contain any of those junk files. So, I propose that Module::Build should have a "distinstall" action, which basically performs an installation from within the distdir. Granted, you can do the same thing with a couple extra shell commands. But putting this feature directly into Module::Build avoids the hassle of figuring out what the actual name of the distdir is. And that is particularly useful for continuous integration systems and automated builds. For example, we use a subclass of Module::Build that looks like this: sub ACTION_distinstall { my ($self, @args) = @_; $self->depends_on('distdir'); $self->_do_in_dir ( $self->dist_dir, sub { $self->run_perl_script('Build.PL') or die "Error executing 'Build.PL' in dist directory: $!"; $self->run_perl_script('Build') or die "Error executing 'Build' in dist directory: $!"; $self->run_perl_script('Build', [], ['install']) or die "Error executing 'Build install' in dist directory"; }); } But _do_in_dir() is not a public method. So I'd much rather see ACTION_distinstall become part of the official API. Perhaps this what is what you intended for the pure_install target? But that seems to just be an alias for install. Thanks for your consideration. -Jeff
Great suggestion. Released as 0.36_17.
Thanks! I'm glad you like it. But it seems that I've now become a victim of my own cleverness. When performing the distinstall action, we need to put the modules in a custom install_base. I see two ways to do this: 1) Pass the options that were given to _this_ Build.PL to the Build.PL in the distdir. In this case, the usage would look like this: perl ./Build.PL --install_base=~/myperl ./Build distinstall 2) Pass additional arguments from the distinstall action to the Build.PL in the distdir. In this case, the usage would look like this: perl ./Build.PL ./Build distinstall --install_base=~/myperl I think option 1 is probably preferable, but I couldn't find a straightforward way to assemble all the potential arguments from $self->{properties}. So I've come up with a rather inelegant implementation of option 2 that looks like this [note the passing of @args, which is taken from @ARGV, to $self->run_perl_script()]: sub ACTION_distinstall { my ($self) = @_; my ($action, @args) = @ARGV; $self->depends_on('distdir'); $self->_do_in_dir( $self->dist_dir, sub { $self->run_perl_script('Build.PL', [], \@args) or die "Error executing 'Build.PL' in dist directory: $!"; $self->run_perl_script('Build') or die "Error executing 'Build' in dist directory: $!"; $self->run_perl_script('Build', [], ['install']) or die "Error executing 'Build install' in dist directory"; } ); } Do you see a better way to do this? -- Jeffrey Thalhammer Imaginative Software Systems www.imaginative-software.com
Subject: Re: [rt.cpan.org #62495] Feature request: New "distinstall" target
Date: Wed, 3 Nov 2010 13:14:06 -0400
To: bug-Module-Build [...] rt.cpan.org
From: David Golden <dagolden [...] cpan.org>
On Wed, Nov 3, 2010 at 1:10 PM, Jeffrey Ryan Thalhammer via RT <bug-Module-Build@rt.cpan.org> wrote: Show quoted text
> Do you see a better way to do this?
I would do it with: $ PERL_MB_OPT="--install_base=~/myperl" Build distinstall -- David
Subject: Re: [rt.cpan.org #62495] Feature request: New "distinstall" target
Date: Wed, 3 Nov 2010 10:46:52 -0700
To: bug-Module-Build [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
On Nov 3, 2010, at 10:14 AM, David Golden via RT wrote: Show quoted text
> I would do it with: > $ PERL_MB_OPT="--install_base=~/myperl" Build distinstall
Perfect! Thanks so much.
RT-Send-CC: dagolden [...] cpan.org, jeff [...] imaginative-software.com
Le 2010-10-27 13:33:51, THALJEF a écrit : Show quoted text
> But this has become problematic. We use the new share_dir option to > manage our non-code resources, which tends to clutter the blib/ > directory with .svn files and other junk. And when you run "./Build > install" from the checkout directory, all that junk gets installed in > /usr/local/lib/perl5 (or wherever).
I recommend to avoid storing 'blib' in your source repository. 'blib' is a build directory that should be the result of the build. It is easier to check what will be installed by looking inside 'blib' before install. Instead store your data files outside of 'blib', and setup your Build.PL so that the 'Build' step copies them to 'blib'. -- Olivier Mengué - http://search.cpan.org/~dolmen/ http://github.com/dolmen/
Le 2010-10-27 13:33:51, THALJEF a écrit : Show quoted text
> But if we run "./Build install" in the distdir, then everything works > beautifully, because the MANIFEST.SKIP makes sure that distdir doesn't > contain any of those junk files.
Jeff, I don't think that MANIFEST.SKIP is used during the 'install' action. Also, to support my assertion that 'blib' is not expected to store input files, try "./Build distclean": 'blib' will be removed. -- Olivier Mengué - http://search.cpan.org/~dolmen/ http://github.com/dolmen/
CC: dagolden [...] cpan.org
Subject: Re: [rt.cpan.org #62495] Feature request: New "distinstall" target
Date: Wed, 16 Mar 2011 12:33:21 -0600
To: bug-Module-Build [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
On Mar 13, 2011, at 9:09 AM, Olivier 'dolmen' Mengué via RT wrote: Show quoted text
> I recommend to avoid storing 'blib' in your source repository. 'blib' is > a build directory that should be the result of the build. It is easier > to check what will be installed by looking inside 'blib' before install. > Instead store your data files outside of 'blib', and setup your Build.PL > so that the 'Build' step copies them to 'blib'.
We don't store blib/ in the source repository. But if you configure M::B with share_dir => 'wherever' , then the .svn, CVS, and other source-control files inside the wherever/ directory also end up in the blib/ directory. I'm not sure if that is a bug or a feature. Jeffrey Thalhammer Imaginative Software Systems vcard: http://www.imaginative-software.com/contact/jeff.vcf
Subject: Re: [rt.cpan.org #62495] Feature request: New "distinstall" target
Date: Wed, 16 Mar 2011 12:40:13 -0600
To: bug-Module-Build [...] rt.cpan.org
From: Jeffrey Thalhammer <jeff [...] imaginative-software.com>
On Mar 13, 2011, at 5:25 PM, Olivier 'dolmen' Mengué via RT wrote: Show quoted text
> I don't think that MANIFEST.SKIP is used during the 'install' action.
True. Thanks for calling that out. I should have said... But if we run "./Build install" in the distdir, then everything works beautifully, because the distdir only contains files listed in the MANIFEST, which never includes those junk files. Show quoted text
> Also, to support my assertion that 'blib' is not expected to store input > files, try "./Build distclean": 'blib' will be removed.
I understand. But that isn't the point. Jeffrey Thalhammer Imaginative Software Systems vcard: http://www.imaginative-software.com/contact/jeff.vcf