[prev in list] [next in list] [prev in thread] [next in thread] 

List:       perl-module-build
Subject:    Re: Adding configure_requires to META.yml
From:       124.188.112.171
Date:       2007-03-18 11:28:48
Message-ID: 45FD2270.9060307 () ali ! as
[Download RAW message or body]

>> This META.yml key, if it exists in a distribution, would inform the 
>> CPAN client that it has dependencies that MUST be installed prior to 
>> the configure script being run at all.
>>
>> These dependencies would always be static, and could never be changed. 
>> Platform related dependency variability in THESE modules would thus 
>> need to be addressed within that dependency independently, presenting 
>> a single facade.
> 
> I think configure_requires is a good step in the right direction.  I'm 
> not completely convinced it solves the entire problem, though.  The one 
> case I'm not sure about is when there are alternative methods of 
> configuration (e.g. a Build.PL and a Makefile.PL) and they have 
> different dependencies (e.g. M::B and EU::MM versions).
> 
> Also, I agree it would be nice to keep this list static, but that may be 
> easier said than done.  Not sure.

I would suggest that you simply have to list the dependencies for BOTH 
of them. At the moment the Makefile.PL produced by Module::Build are 
being done in a maximum-compatibility way anyway, so I think it's 
probably not going to matter.

> Perhaps it's worth noting that it doesn't actually need to be *globally* 
> static, just *locally* static within the context of a single build.  A 
> mini-language for dependencies could accomplish that - for instance, 
> something like this:
> 
>  configure_requires: 'Cwd: 1.2, {PLATFORM=Windows} ? PPM : BuildThing'
> 
> For any given build, that evaluates to either
> 
>  configure_requires: 'Cwd: 1.2, PPM'
>    or
>  configure_requires: 'Cwd: 1.2, BuildThing'
> 
> without the need for truly dynamic configuration.  Locally static 
> properties that come to mind are things like platform or perl version.
> 
> Maybe that's too fancy, though.  Not sure.

Probably, minilanguages add a lot of complexity to the CPAN clients, 
whereas a fully static dependency keeps things very simple to implement.

You also hit the problem of the minilanguage not being featureful enough 
and eventually becoming more complex, and getting loops, and then 
becoming turing complete in it's own right, and at that point well we 
might as well be using Perl anyway, and we've looped back to where we 
started.

More-likely, MOST of the edge cases with static deps can be solved by 
abstracting over the problem and pushing the platform-problems or 
completeness stuff down into the dependency.

So while you have a static dep on Module::Build 1.23, there's no reason 
that Module::Build can't then have a Perl-based 
platform-or-anything-else sensitive configure script.

The only case left would be Makefile.PL AND Build.PL in a single script, 
and I'd suggest you either 1) Don't list deps for Makefile.PL 2) List 
deps for BOTH configure scripts 3) Stop using both (which will happen in 
3-5 years)

>> When Module::Build generated a META.yml it would then automatically 
>> add a configure_requires dependency on the version of Module::Build 
>> used to generate the META.yml in the first place.
> 
> Presumably we'd also let users explicitly state the version of M::B 
> that's required at install-time if they know it, just like we do for 
> other prereqs.  Otherwise, I agree, the current version is a good default.

Absolutely yes. The auto-addition would be a default. I'll note that in 
a few small cases Module::Install does this for the install_share 
command, and it works just fine.

> Also - what happens if a user has an old CPAN, an old M::B, and 
> downloads a META.yml containing a configure_requires entry?  Presumably 
> that entry would be ignored and the user would miss the dependency 
> altogether.  Any thoughts on how to deal with that gracefully?  Maybe 
> something embedded in the Makefile.PL/Build.PL that enforces it or at 
> least warns?

There is no graceful way to deal with this. Previously the problem was 
small enough to be ignored. When Module::Build came along, it made the 
problem larger, but was dealt with partly via also having a Makefile.PL 
with the dist.

As far as I can tell, there's simply no backcompatible way to add this.

That said, for most people, the first thing they do is upgrade CPAN.pm. 
Or at the very least, CPAN recommends that it get upgraded, which people 
will do if the install fails the first time around, which then fixes the 
problem.

Anyone that upgrades CPAN would get the new capabilities, and thus be fine.

On the downside, to my mind this probably means that no modules in or 
depending on by Bundle::CPAN should be using Module::Install, and should 
have an exclusively old-style Makefile.PL.

So that at least the bootstrap problem doesn't prevent you from 
upgrading CPAN to solve the bootstrap problem.

And hopefully we'll have support for this working before 5.10.0, if not 
certainly 5.10.1 will be ok with it, so from there people will have the 
proper.

Once we get this added, the next step is to have the CPAN client itself 
be able to tell if it is fatally out of date. And that will solve the 
problem once and for all, because we will always be able to forcefully 
drag CPAN clients up to the current minimum as it moves.

As for putting something in the Build.PL... yes, I guess, but it would 
be big, ugly, and stuck at the top of the Build.PL scripts for several 
years.

>> Ken, what's involved in having it added to the spec?
>>
> 
> Just me committing it to the spec pod.  I try to be consensusy about it, 
> though, so of course let's make sure we work through the issues in 
> public first.
> 
> One thing I really like about the idea - it would let us be more 
> aggressive about adding new M::B features, e.g. extensions to the 
> dependency syntax that we've been wanting for years.

That's one of the problems it solves, yes.

Adam K
[prev in list] [next in list] [prev in thread] [next in thread]