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