module-build-general — General discussion about Module::Build project

Re: [Module-build-general] B::Module::Info and taint mode

[Scott B. <lis...@ni...>]

On Sun, 25 May 2003 21:37:52 -0500, Ken Williams wrote:
> 
> I'm not sure I understand - you've got a #!/perl line at the beginning 
> of a module file?  That's kind of weird, usually you do that in 
> scripts, not modules.  Or is there some other way to turn on 
> taint-checking that I don't know about?

	You are right it is weird. Now that I think about it, it's
	also a no-op. I forgot that in the hand built makefiles I'm
	trying to replace I explicitly add -T when I invoke each
	module's self test. (e.g. perl -T -I. -MX -eX::_self_test).

	I now see Test::Harness will observe -T (or -t) if that is
	the first line of a test script. I'll migrate to that and
	remove the -T lines in the modules proper.

		Scott

Re: [Module-build-general] B::Module::Info and taint mode

[Ken W. <ke...@ma...>]

On Saturday, May 24, 2003, at 07:28  AM, Scott Bolte wrote:

> 	The Module::Build code scans my perl modules to see which
> 	packages are used by each module. Unfortunately, if a module
> 	has -T to enable taint mode, the call to the O module fails.

I'm not sure I understand - you've got a #!/perl line at the beginning 
of a module file?  That's kind of weird, usually you do that in 
scripts, not modules.  Or is there some other way to turn on 
taint-checking that I don't know about?


  -Ken

[Module-build-general] B::Module::Info and taint mode

[Scott B. <lis...@ni...>]

	The Module::Build code scans my perl modules to see which
	packages are used by each module. Unfortunately, if a module
	has -T to enable taint mode, the call to the O module fails.

	For example:

	   % ./Build test
	   Scanning lib/FIFO.pm for packages
	   B::Module::Info,packages use failed with 255 saying:
	   Too late for "-T" option at /home/user/Dev/lib/FIFO.pm line 1.

	That is really calling:

	   % perl -MO=Module::Info,packages /home/user/Dev/lib/FIFO.pm
	   Too late for "-T" option at /home/user/Dev/lib/FIFO.pm line 1.

	If $extra_args in Module::Info::_call_B() is set to -T
	things work fine.  Should it be Module::Build's responsibility
	to detect the need for -T, or is this a bug report for the
	O module?

		Scott

Re: [Module-build-general] read_config()?

[Scott B. <lis...@ni...>]

> One of the things I'd like to do with M::B in general (and I don't 
> think I've mentioned this anywhere yet) is to help people share data 
> among the various processes that collaborate when building & installing 
> the module.  ....

	Let me know when you decide to tackle that. I'd love to
	help shake out the idea & implementation.

> Until this happens, Scott, you'll probably have to write the 
> information to a temporary file and read that file when you need the 
> information.  ...

	That's what I used to do. I'll go back to that technique.
	However, now that I've made the switch, I'll keep using
	M::B.

		Scott

Re: [Module-build-general] read_config()?

[Ken W. <ke...@ma...>]

On Friday, May 23, 2003, at 06:57  AM, Scott Bolte wrote:

> On Thu, 22 May 2003 09:42:24 -0500, Ken Williams wrote:
>> The META.yml is created when the distribution is created, i.e. right
>> before the distro is uploaded to CPAN or otherwise made available.  It
>> does *not* get re-created when users download, build, and install the
>> module, because they don't typically run the 'distdir' action.
>
> 	In that case I may need a different approach. Among other
> 	things, I need to know how the user is configuring their
> 	installation.

And this is the stuff you're putting in the private data hash?  I think 
I'm starting to see what you mean.

One of the things I'd like to do with M::B in general (and I don't 
think I've mentioned this anywhere yet) is to help people share data 
among the various processes that collaborate when building & installing 
the module.  This includes the PL_files, the test scripts, and the 
Module::Build module/subclass itself.  My dream idea is that you could 
just do

     my $m = Module::Build->instance();
   or
     my $m = Module::Build->current();

or something like that in the various scripts, and you'd get a handle 
to the M::B object (or a reasonable facsimile thereof) whenever you 
needed it.  I haven't thought through what it would take to make this 
happen, though.

Until this happens, Scott, you'll probably have to write the 
information to a temporary file and read that file when you need the 
information.  You could do something like the following in a M::B 
subclass:

   my $file = $self->config_file('module_data');
   my $fh = IO::File->new(">> $file") or die "Can't write to $file: $!";
   print $fh Data::Dumper::Dump($whatever_config_information);
   close $fh;

and then in your PL files:

   my $file = File::Spec->catfile('_build', 'module_data');
   my $fh = IO::File->new($file) or die "Can't read $file: $!";
   my $whatever_config_information = eval do {local $/; <$fh>};
   close $fh;

  -Ken

Re: [Module-build-general] read_config()?

[Scott B. <lis...@ni...>]

On Thu, 22 May 2003 09:42:24 -0500, Ken Williams wrote:
> 
> Sorry I didn't have time to respond before you made your patches, they 
> won't really work unfortunately.

	Don't worry about that. The patch was easy to generate and
	I learned a lot about Module::Build.

> The META.yml is created when the distribution is created, i.e. right 
> before the distro is uploaded to CPAN or otherwise made available.  It 
> does *not* get re-created when users download, build, and install the 
> module, because they don't typically run the 'distdir' action.

	In that case I may need a different approach. Among other
	things, I need to know how the user is configuring their
	installation.

	One of the constraints I have is I try to run in taint mode.
	Not set-uid, but in taint mode none the less. (Exposed
	network service => extreme paranoid mode.) Therefore using
	PERL5LIB to find non-standard install directories won't
	work. Instead I may need to hard code "use lib '...'" in
	some scripts.

	I'll play around with my architecture and see if I can tweak
	my implementation to avoid this issue. I can also fall back
	on the dummy Module::Build object to read the configuration
	directly.

> All the scripts are run from the top level of the distribution, so the 
> path to META.yml is always just 'META.yml' in the current directory.

	You are right, I should be able to count on that.

> > 	One last request, the hash passed into Module::Build::new()
> > 	should have a field dedicated to the calling module's private
> > 	data. ...
> >
> > 		...
> 
> This is a good idea in principle.  Before implementing it though, we'd 
> have to figure out how it interacts with command-line arguments, both 
> to the Build.PL script and to individual actions invoked later.

	I don't mind if you change how it is done. I want that sort
	of functionality moving forward and would prefer to use a
	supported technique instead of polluting Module::Build
	structures.

		Scott

Re: [Module-build-general] bug in Module-Build-0.18

[jk <bil...@fa...>]

Ken Williams wrote:

>
> On Thursday, May 15, 2003, at 09:39  PM, jk wrote:
>
>> Ken Williams wrote:
>>
>>>
>>> Hmmm - care to try another patch?  I think maybe it's the way I'm 
>>> overwriting $ENV{PERL5LIB} in the tests.  Patch below.
>>
>>
>> Sorry for my ignorance, but I don't know how to a patch, I have never 
>> done that before... if you can explain I'll be happy to try if it 
>> might help.
>
>
> Hi JK,
>
> No need to be sorry - there was a time when each of us didn't know how 
> to patch. =)
>
> For a short patch like this, you can just apply it by hand by editing 
> the files it indicates.  Each hunk of the patch gives a little context 
> (line numbers are in the header too), then shows lines that should be 
> removed by putting '-' in front of them, and lines that should be 
> added by putting '+' in front of them.  So you can just make those 
> edits yourself if you want.
>
> If you want to apply a patch automatically, save it in a file called 
> "patch.txt" (or whatever you want), then from the top level of the 
> Module-Build directory issue the command "patch < patch.txt".  More 
> details are in the manual page for the 'patch' command.
>
>  -Ken
>
>
Hi Ken,

Sorry it took so long to do this, been busy.  I patched the basic.t and 
runthrough.t files from a freshly untarred Module-Build-0.18 as 
instructed, so they look like this:

=====from t/basic.t=====
# So 'test' and 'disttest' in Sample/ can see the not-yet-installed 
Module::Build.
{
  my $build_dir = File::Spec->catdir( Module::Build->cwd, 'blib', 'lib' );
  unshift @INC, $build_dir;
  $ENV{PERL5LIB} = $ENV{PERL5LIB} ? "$build_dir:$ENV{PERL5LIB}" : 
$build_dir;
}

chdir 't';
===end t/basic.t====

===from t/runthrough.t===
# So 'test' and 'disttest' can see the not-yet-installed Module::Build.
{
  my $build_dir = File::Spec->catdir( $start_dir, 'blib', 'lib' );
  unshift @INC, $build_dir;
  $ENV{PERL5LIB} = $ENV{PERL5LIB} ? "$build_dir:$ENV{PERL5LIB}" : 
$build_dir;
}
warn "PERL5LIB is $ENV{PERL5LIB}\n";

my $goto = File::Spec->catdir( Module::Build->cwd, 't', 'Sample' );
===end t/runthrough.t===


Then I did the usual install proceedure:
 perl Build.PL config=sitelib=/home/me/data/perl58/
 ./Build
 ./Build test
 ./Build fakeinstall     (to check what it'll do in 'install')
 ./Build install


There were some errors durring the tests.  They are different than the 
errors I was getting before.  The module does seem to get installed at 
the end despite the error messages.

Including the screen output below:

[Module-build-general] [ANNOUNCE] 0.18_01 beta released

[Ken W. <ke...@ma...>]

Hey,

I just released a beta of M::B to CPAN and sourceforge.  The relevant 
Changes file excerpt is below.  It's pretty long!  Please download and 
test this beta if you get a chance.  Thanks.

  -Ken




0.19 TODO:

  - Add tests for verifying signatures as well as creating them.  Skip
    signature tests if we're testing noninteractively, or if the user's
    gpg setup isn't right, etc.

  - Get the installation to nonstandard locations figured out and
    working, finally

0.18_01

  - Alternative distribution layouts are now supported via the
    'pm_files', 'pod_files', 'xs_files', 'PL_files', and 'script_files'
    parameters to new().  This should help people transition from
    MakeMaker, and might even help us write an automatic transition
    tool.

  - Added tests to t/runthrough.t that check to see installation is
    happening correctly.

  - Added an 'add_to_cleanup' parameter to new() that calls
    add_to_cleanup() immediately for the given files.

  - Added experimental code to build a .ppd file, in support of
    ActiveState's "Perl Package Manager". [original patch by Dave
    Rolsky]

  - For authors who use Module::Signature to sign their distributions,
    we now create the SIGNATURE file right in the distribution
    directory, rather than creating it in the top-level directory and
    copying it into place.  This solves problems related to having
    files get out of date with respect to their signatures.

  - The distribution directory (e.g. Sample-Module-0.13/ ) will now be
    deleted during the 'clean' or 'realclean' actions.

  - During testing of modules, blib/lib and blib/arch are now added as
    absolute paths, not relative.  This helps tests that load the
    modules at runtime and may change the current working directory
    (like Module::Build itself does during testing).

  - The $Config{cc} entry on some people's systems is something like
    'ccache gcc', so we now split that string using split_like_shell().
    [Richard Clamp]

  - Added documentation for 'extra_linker_flags' parameter, and added a
    corresponding 'extra_compiler_flags' parameter. [original patch by
    Richard Clamp]

  - The pass-through Makefile created by Module::Build::Compat now
    supports MakeMaker options like POLLUTE=1 and INC.  We also just
    warn & skip when we see any unknown MM parameters, rather than
    dying.  [Dave Rolsky]

  - Fixed an error about how @INC and $ENV{PERL5LIB} interact during
    the testing of M::B itself. [jk <bil...@fa...>]

  - The pass-through Makefile doesn't include 'recommended' M::B
    dependencies in the Makefile anymore, since they're not strictly
    necessary.  In particular, this makes installing M::B itself
    easier.

  - A new 'create_makefile_pl' parameter lets you use
    Module::Build::Compat during the 'distdir' (or 'dist') action to
    automatically create a Makefile.PL for compatibility with
    ExtUtils::MakeMaker.  The parameter's value should be one of the
    styles named in the Module::Build::Compat documentation.

  - When compiling C code, we now respect 'pollute' and 'inc'
    parameters. (XXX - needs docs) [Dave Rolsky]

  - Made the creation of the "install map" more generic.  (XXX - needs
    documentation)

  - Fixed a problem in which add_to_cleanup() didn't note cleanup files
    unless create_build_script() had been called already. [Dave Rolsky]

  - During 'Build dist', we no longer have to load each .pm file (via
    Module::Info) to determine the $VERSION numbers inside.  Instead,
    we call our internal version_from_file() method, which is the same
    thing MakeMaker and PAUSE and search.cpan.org do.  Also fixes a
    failure when Module::Info is installed in a nonstandard directory.
    [reported by Teun Burgers]

  - Fixed some failing test code on Windows - open files can't be
    deleted. [Andrew Savage]

  - The Cygwin platform is now treated as a flavor of Unix rather than
    a flavor of Windows. [chocolateboy]

  - We're now more aggressive about adding temporary C compilation
    files (*.c, *.bs) to the cleanup list. [Dave Rolsky]

  - When constructing the list in META.yml of packages provided by this
    distribution, we now use the same rules as the PAUSE scanner does
    when a single .pm file contains multiple VERSIONs.  [Andreas Koenig]

  - check_installed_status() now works as both a class method and an
    object method (and is documented so).  [Spotted by Dave Rolsky]

Re: [Module-build-general] Re: Figuring out signature stuff

[Ken W. <ke...@ma...>]

On Thursday, May 22, 2003, at 01:35  AM, Autrijus Tang wrote:

> On Wed, May 21, 2003 at 10:09:44PM -0500, Ken Williams wrote:
>>  1) The distdir (e.g. Sample-Module-0.11/ ) is created, including
>>     a META.yml file inside it
>>  2) Module::Signature creates a SIGNATURE file in the distdir, 
>> scanning
>>     the contents of the distdir and the MANIFEST inside it
>>
>> Because it seems like the distribution should be created, then signed.
>
> This can work, except that MANIFEST need to include SIGNATURE in its
> listing.

[following up again on the dropped issue]

This kind of chicken-egg problem is tough to deal with in MakeMaker, 
and I haven't really figured out whether it's any better in M::B yet.  
My standard approach to this is to make a dummy file in the main 
directory, let distdir copy it into the distdir/, and then overwrite 
the copied dummy file with the real info.

The main drawback to this is just that it's a little messy, the 
SIGNATURE in the main directory is superfluous.  But it should *work*.

  -Ken

Re: [Module-build-general] read_config()?

[Ken W. <ke...@ma...>]

Hi Scott,

Sorry I didn't have time to respond before you made your patches, they 
won't really work unfortunately.


On Wednesday, May 21, 2003, at 09:58  PM, Scott Bolte wrote:

> On Wed, 21 May 2003 10:09:19 -0500, Ken Williams wrote:
>>
>> If there's a timing issue I'm not considering, i.e. if the META.yml
>> file isn't created yet, then we might have to figure something else 
>> out.
>
> 	Timing is indeed a problem. I need the data when the PL
> 	files are being processed; well before dir_dist is called.
> 	I think the changes I need are trivial, but I'm not sure
> 	what logic they would break.
>
> 	Why is the META.yml file not created until ACTION_dist_dir()
> 	is called?  If write_metadata($metafile) preceded
> 	process_PL_files() in ACTION_build() the timing issue would
> 	be solved.

The META.yml is created when the distribution is created, i.e. right 
before the distro is uploaded to CPAN or otherwise made available.  It 
does *not* get re-created when users download, build, and install the 
module, because they don't typically run the 'distdir' action.

So if you need to read the META.yml file when people download and build 
the module, it'll be there and it'll work fine.  If you need to read it 
when you're developing the module yourself, just run the 'distdir' 
action once and it'll be available from that point on.


>
> 	Then, to eliminate the guess work by lib/*/foo.PL to find
> 	META.yml, the calls to run_perl_script() in process_PL_files()
> 	should be augmented to include the path to META.yml as the
> 	$postargs argument. That way scripts that care about the
> 	current configuration could find it reliably as $ARGV[0].

All the scripts are run from the top level of the distribution, so the 
path to META.yml is always just 'META.yml' in the current directory.


> 	One last request, the hash passed into Module::Build::new()
> 	should have a field dedicated to the calling module's private
> 	data. By defining the technique to save private data now, you
> 	avoid name collisions later. Something along the lines of:
>
> 		my $build = Module::Build->new
> 		    (
> 			dist_name	=> "Sample",
> 			dist_version	=> "0.1",
> 			module_data	=> {
> 				public	=> "library",
> 				private	=> "gomer pile"
> 			},
> 		    );
>
> 	Predictably I'd like module_data to be included in META.yml.

This is a good idea in principle.  Before implementing it though, we'd 
have to figure out how it interacts with command-line arguments, both 
to the Build.PL script and to individual actions invoked later.

  -Ken

[Module-build-general] Re: Figuring out signature stuff

[Ken W. <ke...@ma...>]

On Thursday, May 22, 2003, at 01:35  AM, Autrijus Tang wrote:

> On Wed, May 21, 2003 at 10:09:44PM -0500, Ken Williams wrote:
>>  1) The distdir (e.g. Sample-Module-0.11/ ) is created, including
>>     a META.yml file inside it
>>  2) Module::Signature creates a SIGNATURE file in the distdir, 
>> scanning
>>     the contents of the distdir and the MANIFEST inside it
>>
>> Because it seems like the distribution should be created, then signed.
>
> This can work, except that MANIFEST need to include SIGNATURE in its
> listing.
>
>> What I'd like to do is to tell Module::Signature what directory to
>> create the SIGNATURE file in, which would be the distdir in this case.
>> Autrijus, could this happen?  Then I'd switch things around in M::B to
>> take advantage of it.
>
> I _think_ the correct way is just to chdir into distdir and sign it. :)

Okay, I can do this, but in general it's best to avoid ever doing a 
chdir(), because if something goes wrong in the middle of an operation 
you could leave the user in the wrong directory.

If in a future version of Module::Signature it becomes possible to sign 
things in a different directory, I'd be interested in doing it that 
way.  Should be fine this way for now, though.  I'll protect it with an 
eval().

  -Ken

Re: [Module-build-general] read_config()?

[Scott B. <lis...@ni...>]

	I had a bit of time so I went ahead and made the changes I
	outlined. It all works, with one caveat.

	find_dist_packages() is called by write_metadata().
	Unfortunately, it is trying to find out information about
	modules in the PL_files list that do not yet exist. It was
	easy to work around, but it means the META.yml file will
	be incomplete when passed to the PL file.

	When META.yml is rebuild by dist_dir it will be complete,
	so this is not a regression. However, the inconsistent
	behavior may surprise people.

		Scott


--- Module/Build/Base.pm.orig	Sat Apr  5 22:45:14 2003
+++ Module/Build/Base.pm	Thu May 22 06:58:36 2003
@@ -704,9 +704,12 @@
   if ($self->{properties}{autosplit}) {
     $self->autosplit_file($self->{properties}{autosplit}, $blib);
   }
-  
-  $self->process_PL_files;
-  
+
+  my $metafile = 'META.yml';
+  $self->write_metadata($metafile);
+ 
+  $self->process_PL_files($metafile);
+
   $self->compile_support_files;
   
   $self->process_pm_files;
@@ -895,7 +898,7 @@
 }
 
 sub process_PL_files {
-  my ($self) = @_;
+  my ($self, $postargs) = @_;
   my $files = $self->find_PL_files;
   
   while (my ($file, $to) = each %$files) {
@@ -905,7 +908,7 @@
     
     # XXX - needs to use File::Spec
     if (grep {!-e $_ or  -M _ > -M $file} @to) {
-      $self->run_perl_script($file);
+      $self->run_perl_script($file, [], [$postargs]);
       $self->add_to_cleanup(@to);
     }
   }
@@ -1080,6 +1083,7 @@
   $node->{version} = $p->{dist_version};
   $node->{license} = $p->{license};
   $node->{distribution_type} = 'module';
+  $node->{module_data} = $p->{module_data};
 
   foreach (qw(requires recommends build_requires conflicts dynamic_config)) {
     $node->{$_} = $p->{$_} if exists $p->{$_};
@@ -1114,6 +1118,7 @@
     my $localfile = File::Spec->catfile( split m{/}, $file );
     my $module = Module::Info->new_from_file( $localfile );
 
+    next	unless $module;
     print "Scanning $localfile for packages\n";
     my %packages = $module->package_versions;
     while (my ($package, $version) = each %packages) {

[Module-build-general] Re: Figuring out signature stuff

[Autrijus T. <aut...@au...>]

On Wed, May 21, 2003 at 10:09:44PM -0500, Ken Williams wrote:
>  1) The distdir (e.g. Sample-Module-0.11/ ) is created, including
>     a META.yml file inside it
>  2) Module::Signature creates a SIGNATURE file in the distdir, scanning
>     the contents of the distdir and the MANIFEST inside it
> 
> Because it seems like the distribution should be created, then signed.

This can work, except that MANIFEST need to include SIGNATURE in its
listing.

> What I'd like to do is to tell Module::Signature what directory to 
> create the SIGNATURE file in, which would be the distdir in this case.  
> Autrijus, could this happen?  Then I'd switch things around in M::B to 
> take advantage of it.

I _think_ the correct way is just to chdir into distdir and sign it. :)

Thanks,
/Autrijus/

[Module-build-general] Figuring out signature stuff

[Ken W. <ke...@ma...>]

Hi people who seem to know about signing modules,

I finally got gpg working, and Module::Signature with it.  Now I'm 
trying to figure how how Module::Build should organize things.  It 
seems to me things should happen in this order when building a 
distribution:

  1) The distdir (e.g. Sample-Module-0.11/ ) is created, including
     a META.yml file inside it
  2) Module::Signature creates a SIGNATURE file in the distdir, scanning
     the contents of the distdir and the MANIFEST inside it

Because it seems like the distribution should be created, then signed.

But it looks to me like the patches submitted to M::B so far create a 
SIGNATURE file in the top-level development directory, based on the 
MANIFEST and MANIFEST.SKIP file (so it knows what files to skip), and 
signs things before the distdir is created.

The problem with this is that developers can override the 
ACTION_distdir() method, doing whatever they want.  For instance, in 
HTML::Mason, the POD documentation gets tweaked before going in the 
distdir.  So the signatures could be wrong if they're done with the 
local versions.

What I'd like to do is to tell Module::Signature what directory to 
create the SIGNATURE file in, which would be the distdir in this case.  
Autrijus, could this happen?  Then I'd switch things around in M::B to 
take advantage of it.

  -Ken

Re: [Module-build-general] read_config()?

[Scott B. <lis...@ni...>]

On Wed, 21 May 2003 10:09:19 -0500, Ken Williams wrote:
> 
> If there's a timing issue I'm not considering, i.e. if the META.yml 
> file isn't created yet, then we might have to figure something else out.

	Timing is indeed a problem. I need the data when the PL
	files are being processed; well before dir_dist is called.
	I think the changes I need are trivial, but I'm not sure
	what logic they would break.

	Why is the META.yml file not created until ACTION_dist_dir()
	is called?  If write_metadata($metafile) preceded
	process_PL_files() in ACTION_build() the timing issue would
	be solved.

	Then, to eliminate the guess work by lib/*/foo.PL to find
	META.yml, the calls to run_perl_script() in process_PL_files()
	should be augmented to include the path to META.yml as the
	$postargs argument. That way scripts that care about the
	current configuration could find it reliably as $ARGV[0].

	One last request, the hash passed into Module::Build::new()
	should have a field dedicated to the calling module's private
	data. By defining the technique to save private data now, you
	avoid name collisions later. Something along the lines of:

		my $build = Module::Build->new
		    (
			dist_name	=> "Sample",
			dist_version	=> "0.1",
			module_data	=> {
				public	=> "library",
				private	=> "gomer pile"
			},
		    );

	Predictably I'd like module_data to be included in META.yml.

	If those changes are made, transferring information from
	the Build.PL file to the various foo.PL files would be solved.
	I can create a patch if you like.

		Scott

[Module-build-general] Cleaning up signature stuff

[Ken W. <ke...@ma...>]

Hi all,

I've moved the Module::Signature-related tests to their own test file 
in CVS, t/signature.t .  Currently I'm not sure they're really working 
correctly, because I'm still without a working Module::Signature 
installation myself, and I may not get that figured out very soon.

Richard, I simplified your test code for faking out the various modules 
when checking the run order, you may want to make sure it's not broken 
now.

  -Ken

[Module-build-general] Re: [Module::Signature] Module::Build works on 5.005 now

[Autrijus T. <aut...@au...>]

On Wed, May 21, 2003 at 10:46:52AM -0500, Ken Williams wrote:
> Thanks to some of the people working on Module::Build patches, recent 
> versions of it work on 5.005.

Congrats.  That means I may finally start to convert my modules
to Module::Build.

> So the first of those caveats could probably be taken out.

Thanks, fixed in depot (@6039), will be release with 0.23 sometime
next week.

Thanks,
/Autrijus/

[Module-build-general] [Module::Signature] Module::Build works on 5.005 now

[Ken W. <ke...@ma...>]

Hi Autrijus,

I noticed the following in the docs for Module::Signature:

        And if you're not worried about compatibility of Perl
        5.005 and earlier versions, willing to inflict the depen-
        dency of Module::Build on your users, and prefer a more
        full-fledged testing package, Iain Truskett's Test::Signa-
        ture might be a better choice.

Thanks to some of the people working on Module::Build patches, recent 
versions of it work on 5.005.  So the first of those caveats could 
probably be taken out.

Thanks.

  -Ken

Re: [Module-build-general] read_config()?

[Ken W. <ke...@ma...>]

On Tuesday, May 20, 2003, at 10:21  PM, Scott Bolte wrote:

> 	Is there any way to cleanly read the configuration information
> 	stored in _build/? I want to determine the version information,
> 	which I plan on storing in Build.PL, in another .PL file.
> 	The following construct is what I came up with:
>
> 		my $build = new Module::Build
> 			(
> 				dist_name	=> undef,
> 				dist_version	=> undef,
> 			);
> 		$build->read_config();
> 		printf("version is \"%s\".\n",
> 			$build->{properties}{dist_version});
>
> 	new() complained unless I called it with dist_name and
> 	dist_version.  (It was also noisy on STDOUT, but that's a
> 	separate issue.)
>
> 	I could duplicate the code in read_config(), but I am loath
> 	to break encapsulation so blatantly.

If you have the META.yml file already created, you could just look for 
a line matching /^version: (\S+)/ in it.  That file is meant to be 
publicly readable, and doing this kind of spot-reading without a full 
YAML parser is very much supported.

If there's a timing issue I'm not considering, i.e. if the META.yml 
file isn't created yet, then we might have to figure something else out.

Also, the new version of Module::Build (0.19) will have a method 
$build->dist_version() that will return the dist_version directly 
instead of doing $build->{properties}{dist_version}.

  -Ken

[Module-build-general] read_config()?

[Scott B. <lis...@ni...>]

	Is there any way to cleanly read the configuration information
	stored in _build/? I want to determine the version information,
	which I plan on storing in Build.PL, in another .PL file.
	The following construct is what I came up with:

		my $build = new Module::Build
			(
				dist_name	=> undef,
				dist_version	=> undef,
			);
		$build->read_config();
		printf("version is \"%s\".\n",
			$build->{properties}{dist_version});

	new() complained unless I called it with dist_name and
	dist_version.  (It was also noisy on STDOUT, but that's a
	separate issue.)

	I could duplicate the code in read_config(), but I am loath
	to break encapsulation so blatantly.

	Is there a better way to get at configuration data?

		Scott

Re: [Module-build-general] signing funkyness

[Richard C. <ric...@un...>]

On Tue, May 20, 2003 at 11:43:29AM -0500, Ken Williams wrote:
> Hmm - this test just makes sure distmeta gets called before sign(), but 
> it doesn't make sure signing actually *works*.  If it was blowing up 
> for you previously, couldn't we just set up that situation and make 
> sure it doesn't blow up?

The previous explosion was occurring at unpack/verify time because the
SIGNATURE could contain a checksum for a stale META.yml.

By forcing the correct ordering, the explosion can't happen.  That's
what Dave patched and I was testing towards.

> The runthrough.t test already has some inactive signature code in it, 
> but I haven't been using it, largely because I've never been able to 
> get Module::Signature working properly. =(

There's as I see it a small problem in running that test,  signing a
distribution is interactive (with gpg at least) and interactive tests
have a tendency to suck[0].

I had problems getting Module::Signature installed a while back when
it was trying to satisfy dependencies for Crypt::OpenPGP, so instead I
just installed the GnuPG module which wraps the gpg binary.  I don't
know if that's improved now though.

[0] much like I taught my granny with eggs

-- 
Richard Clamp <ric...@un...>

Re: [Module-build-general] signing funkyness

[Ken W. <ke...@ma...>]

On Tuesday, May 20, 2003, at 10:57  AM, Richard Clamp wrote:

> On Tue, May 20, 2003 at 04:10:08PM +0100, Richard Clamp wrote:
>> On Tue, May 20, 2003 at 09:59:37AM -0500, Ken Williams wrote:
>>> Still hopeful that a test could be written.
>>
>> Working on it, but the gyrations to usefully fake out 
>> Module::Signature are
>> currently leading to much cursing and gnashing of teeth.  That and I'm
>> having a busy day with RealWork[tm].
>
> I had a stunning realisation as to how I could cheat.  The attached
> test does such.  Caveats - it does no cleanup, and it can't be run
> against anything older than current CVS as there isn't a distmeta to
> override.

Hmm - this test just makes sure distmeta gets called before sign(), but 
it doesn't make sure signing actually *works*.  If it was blowing up 
for you previously, couldn't we just set up that situation and make 
sure it doesn't blow up?

The runthrough.t test already has some inactive signature code in it, 
but I haven't been using it, largely because I've never been able to 
get Module::Signature working properly. =(

  -Ken

Re: [Module-build-general] signing funkyness

[Richard C. <ric...@un...>]

On Tue, May 20, 2003 at 04:10:08PM +0100, Richard Clamp wrote:
> On Tue, May 20, 2003 at 09:59:37AM -0500, Ken Williams wrote:
> > Still hopeful that a test could be written.
> 
> Working on it, but the gyrations to usefully fake out Module::Signature are
> currently leading to much cursing and gnashing of teeth.  That and I'm
> having a busy day with RealWork[tm].

I had a stunning realisation as to how I could cheat.  The attached
test does such.  Caveats - it does no cleanup, and it can't be run
against anything older than current CVS as there isn't a distmeta to
override.

-- 
Richard Clamp <ric...@un...>

Re: [Module-build-general] signing funkyness

[Richard C. <ric...@un...>]

On Tue, May 20, 2003 at 09:59:37AM -0500, Ken Williams wrote:
> >On Mon, May 19, 2003 at 12:22:30PM -0500, Ken Williams wrote:
> >>Also, can a test be written to exercise whatever bug this patch fixes?
> 
> Still hopeful that a test could be written.

Working on it, but the gyrations to usefully fake out Module::Signature are
currently leading to much cursing and gnashing of teeth.  That and I'm
having a busy day with RealWork[tm].

> I've just applied a version of the patch, care to try out CVS?

Works from here. Thanks.

-- 
Richard Clamp <ric...@un...>

Re: [Module-build-general] signing funkyness

[Ken W. <ke...@ma...>]

On Monday, May 19, 2003, at 01:13  PM, Richard Clamp wrote:

> On Mon, May 19, 2003 at 12:22:30PM -0500, Ken Williams wrote:
>
>> Also, can a test be written to exercise whatever bug this patch fixes?
>>

Still hopeful that a test could be written.


> I'm just looking at the Changes in cvs and thinking that there's a
> whole bunch of stuff that I'd consider useful and chunky enough to
> call it a release.  Not that the alternate installing isn't valuable
> but I'm liking the current feature set too.
>
> I'm currently installing the cvs head on my dev boxes, but yes, a
> 0.18_01 would be good too.

I've just applied a version of the patch, care to try out CVS?

  -Ken