headers
Randy W. Sims | 1 Apr 2005 20:50

Re: [Module::Build] Re: Test::META

Ok, this is working now, but there are a few issues.

1. As touched on by Ken and Schwern, per-action prereqs are somewhat 
idiosyncratic. Because dependencies are determined at run time you run 
into problems where for example you set build_requires, and then run 
`./Build.PL && ./Build test` (skipping the 'build' action). Since the 
'test' action depends on the 'code' action instead of the 'build' 
action, the 'build' prereqs are not checked. If the 'test' action did 
depend directly on 'build', there would still be the problem that only 
failed 'test' prereqs would be displayed until resolved and then, as it 
works through the dependencies in turn, failed prereqs for the next 
action will be displayed, as opposed to all failures for the complete 
dependency graph showing up immediately.

PROPOSAL: Create a register_core_dependencies() method called from 
_construct() that registers the dependencies for each of the core 
actions, creating a dependency graph. This graph can be examined at 
during dispatch() time for failed prereqs, and to determine which 
actions to execute based on dependencies. This is in addtion to, and 
possibly replacement of, the depends_on() technique. The two methods 
should work in tandem with no problems. There would also be a 
register_dependencies() method which can be overriden in subclasses so 
that authors can set up dependencies for their custom actions or use 
depends_on().

I'm not quite sure what to do about 'test' depending on 'code' not 
checking for failed 'build' prereqs. I guess we could special case 
'build_*' dependencies for backwards compatability??? Are there other 
cases? If so we might need a translation table that, for example, 
indicates that when 'code' prereqs are being checked we also need to
(Continue reading)

Permalink | Reply | 7 comments |
headers
Randy W. Sims | 1 Apr 2005 21:27

Re: [Module::Build] Priorities for 0.27

Steven Schubiger wrote:
> : On Mar 29, 2005, at 11:25 PM, Randy W. Sims wrote:
> 
> :> Of course, any help is welcome. There is still some work to be done on
> :> the backend classes which form the expressions.
> 
> I have some spare time to divert over.

Module::Build or dEx or CPAN::Metadata? There is plenty to do. For the 
latter two, I can setup an account for you for commit access to the svn 
repository. Just let me know what you're interested in and what you want 
to work on. I'll try to give you as much background info as you need to 
get oriented.

Anonymous access to all repositories is available if you want to go 
ahead and dive in:

Module::Build
cvs -d:pserver:anonymous <at> cvs.sourceforge.net:/cvsroot/module-build co 
Module-Build

CPAN::Metadata
svn co http://svn.versiondude.net/randys/CPAN-Metadata/trunk CPAN-Metadata

dEx
svn co http://svn.versiondude.net/randys/dEx/trunk dEx

John Peacock had mentioned helping on getting dEx to use (bundle?) the 
pure perl version.pm he's been working at. Sorry for the delay 
responding, John. If you're still interested, please let me know.
(Continue reading)

Permalink | Reply | 12 comments |
headers
John Peacock | 1 Apr 2005 21:50
Favicon

Re: [Module::Build] Priorities for 0.27

Randy W. Sims wrote:
> John Peacock had mentioned helping on getting dEx to use (bundle?) the 
> pure perl version.pm he's been working at. Sorry for the delay 
> responding, John. If you're still interested, please let me know.

I've been spinning my wheels lately.  I have a big patch outstanding 
with Subversion, I have been doing major hacking on qpsmtpd, and at 
work, trying to configure a new e-mail server in between network 
crashes.  Consequently, I haven't gotten very much farther with the 
pure-Perl version.pm module. :(

I'll try and check out dEX RSN and see what it looks like I can help 
with.  For the first cut, however, you could simply subclass the current 
version.pm, since I will be supporting the same interface.  That way, 
you aren't being held up by my being spread too thin.  Gut the current 
version comparison code and just use the version objects.  Later, it 
will be trivial to have the subclass check for the actual version.pm and 
then fallback to the pure-Perl edition if it isn't found.

In my OOB e-mail to Randy, I mentioned version::Limit:

http://search.cpan.org/~jpeacock/version-Limit-0.02/lib/version/Limit.pm

and using interval notation:

http://www.mathwords.com/i/interval_notation.htm

to manage the range definitions.

John
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Williams | 1 Apr 2005 22:05
Favicon

Re: [Module::Build] Re: Test::META


On Mar 31, 2005, at 1:24 AM, Randy W. Sims wrote:

> Michael G Schwern wrote:
>> You can use
>> the existing dependency architecture to determine what needs what.  
>> Such as
>> testcover needs both test_requires and testcover_requires.
>
> This is not possible currently. There is no dependency net; it's all 
> done dynamically. There is no way to know what actions depend on which 
> other actions. The depends_on() method simply calls the actions passed 
> to it at the moment that it's encountered. This is one of the few 
> things that I really dislike about M::B.

I think the main problems here are that depends_on() is poorly named 
and it doesn't remember dependencies.

It's poorly named because the dependent isn't always run *before* the 
depender, it's often (see testcover, testdb, code, distsign, and 
distmeta actions) necessary to run the dependent at a specific time 
during the course of running the depender.  In these cases, it's more 
like an invoke_subaction() method or something.

It could certainly be changed to remember dependencies, though.  Or we 
could easily pick out dependencies and throw them into a map to use 
during prereq checking.

  -Ken
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ken Williams | 1 Apr 2005 22:35
Favicon

Re: [Module::Build] Re: Test::META


On Mar 30, 2005, at 6:16 PM, Michael G Schwern wrote:

> On Wed, Mar 30, 2005 at 05:53:37PM -0500, Randy W. Sims wrote:
>> Should we completely open this up so that 
>> requires/recommends/conflicts
>> can be applied to any action?
>>
>> install_recommends => ...
>> testcover_requires => ...
>> etc.
>
> This sounds useful and solves a lot of problems at one sweep.  You can 
> use
> the existing dependency architecture to determine what needs what.  
> Such as
> testcover needs both test_requires and testcover_requires.

There's a problem with this that I'm not sure how to solve: what 
happens when, as part of refactoring, a chunk of one action gets 
factored out to become its own sub-action?  The dependency may well 
pertain to the new sub-action instead of the original action, but 
distribution authors won't have any way to know this - or even if they 
did, they couldn't declare it in a forward-compatible way.

This is precisely the problem we're hitting with 'build_depends' vs. 
'code_depends'.  At one time, the 'build' action was a dependent of the 
'test' action.  So under our proposed dependency model, everything 
would work fine: before running the 'test' action, you run the 'build' 
action, which checks 'build_depends'.
(Continue reading)

Permalink | Reply | 2 comments |
headers
Ken Williams | 1 Apr 2005 22:46
Favicon

Re: [Module::Build] Re: Test::META


On Mar 29, 2005, at 10:44 PM, Randy W. Sims wrote:

> Michael G Schwern wrote:
>> On Tue, Mar 29, 2005 at 08:33:48PM -0500, Randy W. Sims wrote:
>>> A quickie sample implementation to add more meat. I didn't apply yet 
>>> mainly because I'm wondering if we shouldn't bail and do a complete 
>>> roll-back (eg. don't generate a Build script) if there are any 
>>> failed requirements. Or should we bail, for example, during ./Build 
>>> test if there are any test_requires failures? Or continue as is and 
>>> just let it fail when it tries to use the missing requirements?
>> Continue.  Nothing's more frustrating than a system which refuses to 
>> even
>> try to go forward when some checklist is incomplete.
>
> Hmm, I was actually sitting here playing with it again. But I was 
> leaning more towards the 2nd option. The first option of bailing at 
> Build.PL time obviously doesn't make sense as you can complete a build 
> without running test. But does it make sense to test when a required 
> testing module is missing?

Since the 'build', 'test', and 'install' actions are considered the 
"critical path" for installing a module, I think it makes sense to warn 
(not die) during "perl Build.PL" when one of their 
required/recommended/conflict dependencies aren't met.  Thereafter, 
only die/warn when running an action and its required/recommended 
dependencies aren't met.

  -Ken
(Continue reading)

Permalink | Reply | 4 comments |
headers
Christopher H. Laco | 1 Apr 2005 22:55
Gravatar

Re: [Module::Build] Re: Test::META

Ken Williams wrote:
> Since the 'build', 'test', and 'install' actions are considered the 
> "critical path" for installing a module, I think it makes sense to warn 
> (not die) during "perl Build.PL" when one of their 
> required/recommended/conflict dependencies aren't met.  Thereafter, only 
> die/warn when running an action and its required/recommended 
> dependencies aren't met.
> 
>  -Ken
> 
> 

I'll show my lack of historical knowledge here, and this is swaying just 
a little off topic.

If build, test, and install are considered the critical path, why was 
Build/make never changed to simple run "test" always as part of the 
builds success or failure?

Just curious. In a way, I'd be much happier if 'perl Build' or 'make' 
outright failed if the tests didn't pass, just like if there was a 
c/linking error.

-=Chris
Attachment (smime.p7s): application/x-pkcs7-signature, 3178 bytes
Permalink | Reply | 2 comments |
headers
David Golden | 1 Apr 2005 22:59

Re: [Module::Build] Re: Test::META

Ken Williams wrote:

>
> On Mar 30, 2005, at 6:16 PM, Michael G Schwern wrote:
>
>> On Wed, Mar 30, 2005 at 05:53:37PM -0500, Randy W. Sims wrote:
>>
>>> Should we completely open this up so that requires/recommends/conflicts
>>> can be applied to any action?
>>>
>>> install_recommends => ...
>>> testcover_requires => ...
>>> etc.
>>
>>
>> This sounds useful and solves a lot of problems at one sweep.  You 
>> can use
>> the existing dependency architecture to determine what needs what.  
>> Such as
>> testcover needs both test_requires and testcover_requires.
>
>
> There's a problem with this that I'm not sure how to solve: what 
> happens when, as part of refactoring, a chunk of one action gets 
> factored out to become its own sub-action?  The dependency may well 
> pertain to the new sub-action instead of the original action, but 
> distribution authors won't have any way to know this - or even if they 
> did, they couldn't declare it in a forward-compatible way.
>
I freely admit that I haven't been following this thread closely (I
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ken Williams | 2 Apr 2005 00:57
Favicon

Re: [Module::Build] Re: Test::META


On Apr 1, 2005, at 2:55 PM, Christopher H. Laco wrote:
>
> If build, test, and install are considered the critical path, why was 
> Build/make never changed to simple run "test" always as part of the 
> builds success or failure?
>
> Just curious. In a way, I'd be much happier if 'perl Build' or 'make' 
> outright failed if the tests didn't pass, just like if there was a 
> c/linking error.

Yeah, good question.  I guess it's mostly historical.  There's nothing 
really stopping us from creating an 'everything' action that does a 
'build', 'test', and 'install' all in a row.  Or maybe just the 'build' 
and 'test'.

Anyone else like that idea?

  -Ken
Permalink | Reply | 0 comments |
headers
Steffen Schwigon | 1 Apr 2005 18:34
Picon
Favicon

[Module::Build] Bug? Makefile.PL in subdirs triggers MakeMaker stuff in M::Build

Hi!

I'm converting a project to Module::Build and have found a strange
behavior.

If I accidentally have an old Makefile.PL in a (any) subdirectory of
my package then Module::Build (or a used module) seems to read this
file and especially tries to do what's written in that Makefile.PL.

E.g., this project:
   .
   ./lib
   ./lib/HotPkg
   ./lib/HotPkg.pm
   ./lib/HotPkg/SubPkg.pm
   ./lib/HotPkg/Makefile.PL          <----- accidentally here

This happens:

$ perl Build.PL
...
$ ./Build 
/usr/bin/perl lib/HotPkg/Makefile.PL lib/HotPkg/Makefile
Could not open 'HotPkg.pm': No such file or directory at /usr/share/perl/5.8/ExtUtils/MM_Unix.pm line 3038.

If I (just as experiment) copy the ./lib/HotPkg.pm to ./ then the same
magic generates a Makefile.

The ancient ./lib/HotPkg/Makefile.PL contains:
(Continue reading)

Permalink | Reply | 10 comments |

Gmane