Packlist 2.0
MYMETA + installed file details
?
On Dec 17, 2012 12:36 AM, "Tim Bunce" wrote:
> On Sun, Dec 16, 2012 at 04:53:49PM -0800, Michael G Schwern wrote:
> > On 2012.12.16 11:57 AM, Leon Timmermans wrote:
> >
> > >> * Where to put the database? What about non-standard install
> location
dam
On Sun, Feb 5, 2012 at 12:23 PM, David Golden wrote:
> On Sat, Feb 4, 2012 at 5:17 PM, Adam Kennedy wrote:
>> That's how Module::Install's requires_from does it too.
>>
>> I should look at zilla's code and see how it runs, might be worth
>> aligning
>> On Sat, Feb 4, 2012 at 1:32 AM, Adam Kennedy
>> wrote:
>>> While I agree it needs to finish, I do kind of wish dependencies could
>>> be enforced at the build module level so that tests couldn't run until
>>> dependencies are satisfied.
>>
>
1:50 PM, David Golden wrote:
> On Sat, Feb 4, 2012 at 9:43 PM, Adam Kennedy wrote:
>> If the goal is only to pick up versioned dependencies, I'm surprised
>> we even need to bother with that.
>
> It picks up as many "standard" dependencies as it can, but tr
While I agree it needs to finish, I do kind of wish dependencies could
be enforced at the build module level so that tests couldn't run until
dependencies are satisfied.
Adam
On 4 February 2012 10:22, Leon Timmermans wrote:
> 2012/2/3 Alberto Simões :
>> Hello
>>
>> Builder->new seems to check i
Define "manually"
Adam K
2011/4/25 Alberto Simões :
> Hello
>
> I have a module (Text::BibTeX) that is cleanly installing when using cpan,
> but fails two tests when I try to install manually, using Strawberry Perl.
>
> The tests are using a C library, getting the results through XS, and
> conver
uires" command could dispatch to two different functions
for installers and authors.
Adam K
On 10 March 2011 07:09, Christopher J. Madsen wrote:
> On 3/8/2011 11:15 PM, Adam Kennedy wrote:
>> On 8 March 2011 12:56, Christopher J. Madsen wrote:
>>> Dist::Zilla is the first attem
Module::Build, like ExtUtils::MakeMaker and Module::Install, were
written for a world where you don't have configure-time dependencies.
Thus the trend to large and involved single packages with everything
included, just as things like CGI.pm were before it in the days when
we didn't have any depend
On 8 March 2011 12:56, Christopher J. Madsen wrote:
> Dist::Zilla is the first attempt to separate the authoring role from the
> installing role that's achieved significant traction. As such, it will
> never replace the "installing" side of MakeMaker or MB. There's been
> some talk about an "Ins
While the upgrade to support configure-time dependencies has been
finished now (5.10.1 is where it hit core) we haven't yet started to
the deprecation of support for older clients.
The plan as I understand it is that at some point in the future, M:B
and M:I and friends will trap missing configure-
On Wed, Feb 24, 2010 at 12:17 AM, Andreas J. Koenig
wrote:
>>>>>> On Tue, 23 Feb 2010 21:57:07 +1100, Adam Kennedy said:
>
> > There is no reason to impose this kind of thing on end users, as the
> > failure does not actually prevent the module from working, a
On Tue, Feb 23, 2010 at 9:13 PM, Andreas J. Koenig
wrote:
> > The signature test isn't really a test. Its not testing that the code
> > does its job, its testing that it passes its signature. Its not a
> > functionality test, its a security measure, and doesn't really belong
> > in the test
There's a secondary benefit for the author to be sure the signature
was produced correctly.
If that's the case, then at most the test could live in /xt
But there's absolutely no reason to put it into /t
Adam K
On Tue, Feb 23, 2010 at 11:26 AM, Michael G Schwern wrote:
>
You should not add MYMETA.yml to the MANIFEST, it will NEVER ship to CPAN.
Remove the signature test.
Adam K
On 23 February 2010 01:29, Hinnerk Altenburg wrote:
> Hi,
>
> I got problems with the MYMETA.yml and the recommended signature test from
> http://github.com/audreyt/module-signature/blob
Addition to David's reply, the use of xt was suggested as a
convenience (not as a requirement) that tools may or may not choose to
use to indicate tests that run during RELEASE_TESTING. They won't
define tests that MUST be run during RELEASE_TESTING.
Adam K
2009/11/25 Dave Rolsky :
> It seems lik
> What do people think?
I think both (1) and (2) are going to suffer from architecture
dependency problems, amplified by recursion.
I also think that blindly using a newer version of something without
knowing if it's compatible with the bundled one is asking for trouble.
But that's more a call to
YAML::Tiny supports a few obscure cases that are META.yml specific
that even YAML.pm doesn't.
The Module::Install implementation of MYMETA.yml uses YAML::Tiny.
Adam K
2009/9/6 David E. Wheeler :
>> The other option I'm considering is to create a new, CPAN::Meta
>> distribution and rely on that t
+1
2009/9/4 David Golden :
> What do people think about quieting more of the messages that
> Module::Build prints to the terminal?
>
> For example, there tends to be a lot of "checking this... looks good",
> "checking that... looks good", "Deleting this", "Removed this", etc.
> type messages.
>
>
Dave
The one thing here you need to remember, even if you don't know how it all
works, is that some of the toolchain features work (conceptually) very
different depending on whether they are the core or not.
configure_requires being the standout example, it would be completely
compromised and lar
2009/8/9 David Golden
>
> For #2, I think we should change M::B to do either one of these:
>
> (a) specify Module::Build version 0 in configure_requires if not specified
>
Well that one's out.
It says "Please make sure a woefully antiquated version of M:B completely
insufficient for install thi
Out of curiosity John, why would need to do an automatic run-time
module load at all?
Adam K
2009/7/19 John Peacock :
> Adam Kennedy opened a ticket against Module::Build, which David Golden
> correctly
> interpreted as being version.pm's fault (in the pure Perl release only). I&
I find all three equally cringe'worthy (those two AND the original use
version ...)
Adam K
2009/7/16 Gisle Aas :
> On Jul 15, 2009, at 23:36 , David Golden wrote:
>
>>
>>> Seems like a good reason now to do this then. Perhaps it's better to
>>> write:
>>>
>>> our $VERSION = version->declare("v1
2009/6/14 Michael G Schwern :
>> Just noting that it's not necessarily all rainbows and puppies, so if
>> svn is working fine it's not compulsory that you move.
>
> Fortunately github lets you download a tarball or zip of any commit or tag.
> No version control software required.
I meant more inte
-0
svn is still more common and easier to both install and use on more
platforms, which might be relevant given that M:B needs to be debugged
across many many platforms.
Of course, since I'm not a committer I don't really count...
Just noting that it's not necessarily all rainbows and puppies, s
Beyond not-supporting it, the other biggie is that this completely
violates encapsulation.
Worse, since version.pm wasn't involved in the serialisation, any YAML
parser that DID support this would just stuff a HASH full of the data
you see there and blindly bless it into any class it's told. There
2009/5/6 Jonathan Yu :
> The real question at hand here is: for modules that provide both a
> Makefile.PL and Build.PL, which should be preferred? More than that,
> from the perspective of CPAN authors, is it even useful to provide
> both? Now that Module::Build is a core module, maybe only a Build
Oh wait, you're right. I misread.
2009/4/28 Ken Williams :
> On Thu, Apr 23, 2009 at 9:45 PM, Adam Kennedy
> wrote:
>> 2009/4/23 Zefram :
>>> Why shouldn't this situation be an error, and die because "1.06" can't
>>> be compared wi
2009/4/25 Michael G Schwern :
>> Strict in what we emit: v1.2.0
>> Liberal in what we accept: v1.2
>
> +1
And look how well that's worked for email...
I think it's worth noting that in David's results, a total of only 4
modules on the whole CPAN have tuple elements higher than 999.
Adam K
2009/4/23 David Golden :
> On Thu, Apr 23, 2009 at 4:18 AM, Adam Kennedy
> wrote:
>> A more interesting question then becomes, does a
2009/4/24 John M. Gamble :
> 2) CPAN packages are named using that number in META.yml. See above.
Can someone remind me why the package naming matters again?
> To me, an X.YY version
> number goes to X.YY.00, and that's how I've been numbering them.
I think the "obvious" requires that you have d
2009/4/24 Eric Wilhelm :
> I would like to see #3, and I suspect that it could be implemented in
> 5.12.0, excepting certain caveats for last-century compatibility, but
> maybe if it changes now, it could make some sense in 9 more years.
You mean 6.2.0 right? Because the one-column scheme ran out
2009/4/23 Zefram :
> David Golden wrote:
>>The problem -- the real, core problem -- is that perl *has* to be able
>>to compare them.
>>
>> # Foo.pm
>> package Foo;
>> use version; our version = qv("v1.7.0");
>> 1;
>>
>> # main.pl
>> use Foo 1.06; # dies --> 1.06 is 1.60.0
>
> Wh
2009/4/23 Eric Wilhelm :
> 1.0101 is 1.10.100. But, the point: you can't reliably convert tuples
> to numbers if any part is over 999, so you have to convert the float to
> a tuple to compare with a tuple.
Any excellent summary of the core problem.
A more interesting question then becomes, does
2009/4/23 Ken Williams :
> +1 for Schwern here. Dotted tuples, away with the silly
> you-must-always-use-3-digits rule.
What are your plans for $], and all the code everywhere that does stuff with it.
Adam K
2009/4/23 Eric Wilhelm :
> I think this comes at it from the wrong end. You have to go from floats
> to tuples to compare between them. So, 1.0101 -> 1.10.1.
You didn't zero-pad to the nearest triplet. That's actually 1.10.100.
Adam K
The most common float <---> tuple translation approach (which is the
one Perl itself uses) involves the idea of zero-padded triplets.
D:\cpan\trunk\Perl-Dist-Strawberry>perl -e "print $]"
5.01
As far as I know, when extended to CPAN versions, the convention has
been to pad out decimals to the
2009/4/23 Michael G Schwern :
> Whether you like it or not, humans eyeball version numbers all the time and
> they don't think to study the documentation... if they can find it or even
> think they might need it to parse something as simple (should be simple) as a
> version number.
>
> Disallowing
2009/4/22 Yitzchak Scott-Thoennes :
> I didn't see any "in META.yml" restriction in David's dicta. And I
> would be very surprised if META.yml publicized a different version than
> I picked.
META.yml is a machine to machine format, theoretically humans aren't
even supposed to be reading it except
2009/4/22 David Golden :
> On Tue, Apr 21, 2009 at 1:49 PM, Adam Kennedy
> wrote:
>> 2009/4/21 David Golden :
>>> Any version that does not appear in the form of type (a) or type (b)
>>> is considered invalid. The behavior of modules encountering invalid
>>
2009/4/21 David Golden :
> I'm not worried about enforcement just yet. I see this is a
> recommended convention -- to be followed by aggressive communication
> if there's a consensus.
For META.yml, I'm not the least bit interesting in recommendations of any kind.
Agree on a design, whoever think
2009/4/21 David Golden :
> Any version that does not appear in the form of type (a) or type (b)
> is considered invalid. The behavior of modules encountering invalid
> versions is undefined.
Well that's not particularly helpful.
Also, why exclude v1.23 useful as a tuple...?
Adam K
2009/4/21 Michael G Schwern :
> I was almost convinced, then I remembered what caused this whole problem.
> Class::Delegation went from 1.06 to 1.7.1. That's 1.60.0 to 1.7.1 in your
> system.
Of course that's what it means. The fact you don't have to type the
last zero is just a convenience...
A
2009/4/21 Michael G Schwern :
> X.Y.Z is always a tuple. It's obviously not a number. What else could it be?
> It does not need a leading v.
>
> Same goes for X.Y.Z.A and so forth. So they don't need any disambiguation.
It only doesn't need disambiguation if you are able to intuit it.
We're w
2009/4/20 Eric Wilhelm :
> I'm fine with the current behavior, but the spec needs to be clarified.
> What's the canonical handling? Is it 'version->new($meta->{version})'?
>
> http://module-build.sourceforge.net/META-spec-current.html#version_specifications
Definitions of file formats based solel
2009/4/19 Jan Dubois :
> On Sat, 18 Apr 2009, Michael G Schwern wrote:
>> Let's count the different ways we might have to parse a version.
>>
>> X ok, sort it as a number.
>> X.Y hopefully that's a decimal number and not a dotted pair
>> X.Y_Z oh right, alpha versions. Strip _Z off and sort
> Part of the point of META.yml is to make it easier to get metadata about a
> package. No more scraping around in $VERSION or special parsing logic or
> guessing. This reintroduces special parsing logic. To this end, the META.yml
> version should be normalized to a simple decimal. use version-
2009/4/19 Eric Wilhelm :
> I've been thinking that a developer tool would simply read distin.yml
> and generate a Build.PL. This probably starts to resemble distzilla.
I bet that my Module::Install::DSL Makefile.PL's are still smaller
than the config files that generate the Build.PL.
> And perha
Indeed. While configure_requires fixes Module::Build in the general
case, it's by no means going to fix the fact that the passthrough is
not a valid solution to the problem in the first place.
Adam K
2009/3/23 Eric Wilhelm :
> But it does mean that those wishing for the compatibility layer to all
There might be implications for the MYMETA.yml though...
That said, personally, I think it's probably enough to read in the
existing META.yml, and modify the requires/etc keys, rather than
generate it from scratch.
Adam K
2009/3/21 Randy J. Ray :
>> I don't think it's really necessary. The dist
Excellent.
I'll call that the standard then and knock up a FFR:NoIndex.
Adam K
2009/2/10 Andreas J. Koenig :
>>>>>> On Tue, 10 Feb 2009 12:19:06 +1100, Adam Kennedy
>>>>>> said:
>
> > Hi gang
> > Can someone in the know please clarify
Hi gang
Can someone in the know please clarify for me EXACTLY what the file
and directory entries in no_index mean?
Are they always considered to be multi-part root-relative
unix-normalised paths? (i.e. foo/bar )
Or could they be seen as referring to other things?
I want to write up a File::Fin
The problem here is defining an "environment"...
The only two big use cases as for doing arch-level alternate deps
(which is a mixture of looking for MSWin32 or (MSWin32||cygwin) and
looking for libraries (all those XS modules).
The number of things you have to know about the target environment
j
2009/1/29 David Golden :
> All that 'maybe_requires' indicates in META.yml is that these are
> requirements that may or not apply and that can only be resolved by running
> Build.PL or Makefile.PL.
I'm struggling to come up with many reasonable use cases for "maybe",
bearing in mind that we're goi
Fair enough, I'm agnostic enough to live with it either way.
Adam K
2009/1/29 David Golden :
> On Wed, Jan 28, 2009 at 1:11 PM, Adam Kennedy
> wrote:
>>
>> There's not really any need for dynamic_config: 0 that I can see,
>> since it means "Can META.yml b
racies, because it doesn't have back-compat issues. I
just change it later and make sure it's sufficiently hard to use it
that only the dedicated people know about it. :)
Adam K
2009/1/28 David Golden :
> On Tue, Jan 27, 2009 at 8:00 PM, Adam Kennedy
> wrote:
>>
>> I k
I know we kind of agreed on METALOCAL.yml at the last QA hackathon,
but I have to say I've come around to the shorted (and 8.3-compatible
fwiw) MYMETA.yml.
It's also easier to type.
I'm gunna do a first implementation of my_meta; as a specific command
in M:I's next release, to give us some stuff
2009/1/28 Michael G Schwern :
> A while ago, Audrey suggested inverting the process. Rather than having a
> program that spits out meta-data, have meta-data which might contain programs.
>
> Why is this useful? If you have a program it can do anything, this is the
> basic Makefile.PL/Build.PL/con
2009/1/26 Nicholas Clark :
> On Mon, Jan 26, 2009 at 09:15:38PM +1100, Adam Kennedy wrote:
>> Unfortunately, any configuration language would eventually trend
>> towards being turing complete, and thus the final end-point for the
>> configuration language ends up with us ju
2009/1/26 Eric Wilhelm :
> We need to move toward things looking directly at META.yml. I'm leaning
> toward just pretending that they do (and that people upgrade software.)
As a starting point, I've been pondering just going ahead and
implementing it in Module::Install,
so that we have it working
2009/1/26 Yitzchak Scott-Thoennes :
> On Sun, January 25, 2009 9:20 pm, Adam Kennedy wrote:
>> And because things like ExtUtils::MakeMaker don't understand anything
>> more complicated than "depends", all other recommends stuff gets folded
>> down into a regula
2009/1/26 Michael G Schwern :
> Adam Kennedy wrote:
>> Of course, the "recommends" keyword also doesn't mean what you think
>> it means and is largely pointless.
>
> Near as I can figure what Adam's complaining about, since apparently we're
> mind
Of course, the "recommends" keyword also doesn't mean what you think
it means and is largely pointless.
Adam K
2009/1/25 Yitzchak Scott-Thoennes :
> On Sat, January 24, 2009 8:07 pm, Lyle wrote:
>> Hi All,
>> Looking more at makefiles, in your Makefile.PL or Build.PL you have
>> the usual pre-req
> Adam has proposed (I think) that Config.pm can specify a sharedir and (I
> think) that we can fallback to an 'auto/' location in @INC as per
> File::ShareDir. I posit that this then becomes a vendor+user education
> project, but haven't examined it in much detail.
Correct. Since Config is alrea
2009/1/23 Eric Wilhelm :
> Ok, so Module::Build would look for a sharedir in Config.pm and
> File::ShareDir would do the same?
That would be the basic idea, yes. Although a real might need to be a
little more nuanced.
> That sounds reasonable, but what about an application which simply wants
> to
2009/1/19 Eric Wilhelm :
> By "real share path", do you mean e.g. /usr/share ?
Yes, that.
>
> And what is "configure it"?
./Configure I guess... setting it when you build Perl itself, so that
it ends up in Config.pm.
Adam K
My experience when writing File::ShareDir in the first place was that
the underlying Perl configuration structure in Config only understands
a limited set of directory types.
The set of directory types does NOT include the concept of "share"
(readonly per-installation data files).
The key concept
Personally, I don't mind at all.
All Strawberry installs since the October release support
configure_requires out of the box and are configured to always prefer
Build.PL (pretty sure on that last one, but I'll double check it for
the January release).
Adam K
2009/1/16 Eric Wilhelm :
> So, I'm in
2009/1/16 Eric Wilhelm :
> # from demerphq
> # on Thursday 15 January 2009 03:39:
>
>>If this is meant to deal with installation issues then perhaps it
>>should use the "schedule file for deletion at reboot" API, similar to
>>how ExtUtils::Install deals with DLL's that are in use by the
>>installat
Looks fine, although personally I'd...
sleep $i;
... and maybe ...
$self->log_info("Couldn't remove '$_'; trying " . (5 - $i) . " more times\n");
Adam K
2009/1/15 David Golden :
> Based on the thread about my file deletion heisenbug and the likelihood that
> a virus scanner was keeping files o
Just reporting in that 3.1012 release WORKSFORME on my XP boxes.
Adam K
(fires up the Strawberry builder again)
Agreed.
Indefinite retry is not a good idea, but limited retry should cover
almost every case that is laggy without preventing legitimate failures
from happening.
Adam K
2009/1/15 Jan Dubois :
> On Wed, 14 Jan 2009, David Golden wrote:
>> On Wed, Jan 14, 2009 at 7:16 PM, Adam Kennedy
ge 0.31011 0.31012_01
> svn commit
> perl Build.PL
> perl Build
> perl Build makedist
Give me 6 months and I'll automate it in Padre for you...
Or something...
Adam K
2009/1/15 Eric Wilhelm :
> # from Adam Kennedy
> # on Wednesday 14 January 2009 06:52:
>
>>As soon
If the "delete pending" thing is detectable, we could even just fix it
in error handling.
if ( $@ =~ /delete pending/ ) {
print "Waiting for files to delete...\n";
sleep(5);
run_it_again();
}
Adam K
2009/1/15 David Golden :
> On Wed, Jan 14, 2009 at 3:29 PM, Jan Dubois wrote:
>
>> I
The CPAN has a concept called a development release that was created
SPECIFICALLY to solve this problem.
As soon as there's a packaged tarball living at an arbitrary URL, any
Strawberry machine can trivially just run the following to test it.
pip http://url...
Pack up a dev release and get the w
fair, this may have existed in the previous version too, but was
being masked by the other bug.
We need to find the offending bad skip and upload 0.31012 :/
And get our release manager access to a Win32 box to test on :)
Adam K
2009/1/13 David Golden :
> On Mon, Jan 12, 2009 at 7:44 PM, Adam
, but makes prod releases more sensitive to
bad releases.
Adam K
2009/1/13 Adam Kennedy :
> 2009/1/13 Eric Wilhelm :
>> And nobody noticed it or mentioned it for 3 months (let alone the set of
>> two alphas starting over a month ago.)
>
> The main reason that nobody noticed it
2009/1/13 Eric Wilhelm :
> And nobody noticed it or mentioned it for 3 months (let alone the set of
> two alphas starting over a month ago.)
The main reason that nobody noticed it is that the majority doing CPAN
installs is using Strawberry, and that updates to the latest version
of everything eve
AIL rate for 0.31 on MSWin32. When I run the tests I see the
tilde test failing.
M:B is toolchain, so really we should be at 100% PASS on all CPAN
Testers platforms all the time (ignoring spurious results)
Adam K
2009/1/13 Eric Wilhelm :
> # from Adam Kennedy
> # on Monday 12 January
I have taken the liberty of adding co-maint for you on M:B:Dumper, I'm
sure Ken won't mind.
Adam K
2009/1/13 Eric Wilhelm :
> Well, it has been released... but not really?
>
> -- Forwarded Message: --
>
> Subject: Failed: PAUSE indexer report
> EWILHELM/Module-Build-0.3101.tar.g
2009/1/13 Eric Wilhelm :
> # from David Golden
> # on Thursday 08 January 2009 20:51:
>
>>As far as I can tell, I think this is now ready to be released to CPAN
>> as 0.3101 and then I'll prepare the patch file for p5p to merge it
>> back into bleadperl.
>
> I think we're in agreement that this set
Methinks a nightly cron job to detect differences between core and
current CPAN stable and mail a snarky message to p5p? :)
Adam K
2009/1/8 David Golden :
> Ken -- I tried to be "helpful" sending p5p a patch to merge 0.31 into blead
> for the 5.10.1.
>
> Unfortunately, as per my other email, they
It's SUPPOSED to have everything upgraded... there's code specifically
to so. including a CPAN.pm upgrade command.
Either it was updated post build time, or there's a bug in Perl::Dist
I need to squash.
Actually, I would like to do an updated release, because another few
minor things snuck into t
I'll see to it that the pony goes into blead asap.
Adam K
2008/10/4 Nicholas Clark <[EMAIL PROTECTED]>:
> On Sat, Oct 04, 2008 at 01:55:50PM +1000, Adam Kennedy wrote:
>
>> The magic ponies will be introduced in 5.8.9 and 5.10.1. You indeed
>> will never have to
2008/10/3 Michael G Schwern <[EMAIL PROTECTED]>:
>> 2008/9/30 Matt S Trout <[EMAIL PROTECTED]>:
>>> If the world upgraded regularly, Module::Build wouldn't be such a disaster
>>> anyway :)
>
> Adam Kennedy wrote:
>> True, but it's FAR mor
True, but it's FAR more palatable to say "Just upgrade ONCE, and
you'll never have to think about it again" compared to upgrading
continuously.
Adam K
2008/9/30 Matt S Trout <[EMAIL PROTECTED]>:
> If the world upgraded regularly, Module::Build wouldn't be such a disaster
> anyway :)
2008/9/30 Michael G Schwern <[EMAIL PROTECTED]>:
> chromatic wrote:
>> s/Module::Install/Autobundling/
>>
>> Autobundling is fine for end-user all-in-one no-user-servicable-parts-inside
>> applications, but the CPAN is not the place for static linking. It would be
>> nice not to drag Perl kicking
2008/9/30 Michael G Schwern <[EMAIL PROTECTED]>:
> That said, people choose based on convenience, not abstract, long term safety.
> So it's for the best that Module::Build absorb every convenience feature
> from MI.
For the record, I concur entirely with this solution.
Module::Install was a ste
2008/9/29 Michael G Schwern <[EMAIL PROTECTED]>:
> Rather than a brute force "bundle your dependencies" there is now
> configure_requires. You can set configure_requires => { 'Module::Build' =>
> X.YY } in your Build.PL and an up-to-date CPAN shell will do the right thing.
> We've pressed hard to
David E. Wheeler wrote:
On May 20, 2008, at 21:20, Eric Wilhelm wrote:
# from David Golden on Tuesday 20 May 2008:
On Tue, May 20, 2008 at 11:03 PM, Adam Kennedy
Personally, I'd like to see configure_requires: finalised first
before we start dealing with test_requires, so that we hav
would upgrade itself before trying to install anything.
Adam K
Eric Wilhelm wrote:
# from Adam Kennedy
# on Tuesday 20 May 2008:
That said, it's possible that we might be able to fix this problem
with METALOCAL.yml...
I'm failing to see the target along that trajectory.
This is correct basically all correct.
The FreeBSD people in particular have a particularly strong reason to
prefer having a distinction between build_requires and test_requires.
The impression I got was that this was a good idea, but because it
wasn't immediately pressing, it needed to go th
Wouldn't that require a clear understand of the meaning of recommends?
The only clear guidance I've seen is "the same as Debian's meaning"
which is "You almost always want to have this, but if you are on a
resource-contrained environment you can leave it out if you must".
Adam K
Randy J. Ray
Eric Wilhelm wrote:
# from David Golden on Tuesday 20 May 2008:
On Tue, May 20, 2008 at 11:03 PM, Adam Kennedy
Personally, I'd like to see configure_requires: finalised first
before we start dealing with test_requires, so that we have the
option of solutions that themselves lev
configure_requires MUST be static, and can NEVER be programmatic.
That's why it exists in the first place.
(This response may not get to the list Eric)
Adam K
Eric Wilhelm wrote:
# from Andreas J. Koenig
# on Monday 17 March 2008 22:34:
(3) mention configure_requires
Does that hav
> Heed also: all we do right now is pass through a configure_requires
> parameter from new() to the META.yml.
Great, that's all we need for the basic implementation.
> The original idea from Adam was to automatically add
> configure_requires => {M::B => $M::B::VERSION} to every M::B-using
> distr
>
> Maybe we can just upgrade the CPAN shell then?
>
> Perhaps what we need is a nice little bundle which allows a user to come
> up to date on any box in under a few minutes.
>
Which is all well and good, except for that whole universal education thing
again.
Half the point of configure_requires
>
> But I think it's overkill for anything but the most important
> modules. It's
> an O(1) problem. That is, you don't have to repeat it for every single
> module. Once you've installed Module::Build or upgraded your CPAN shell
> once
> you're done.
O(1) of course assumes you only have one po
On 13/12/2007, David Golden <[EMAIL PROTECTED]> wrote:
>
> On Dec 12, 2007 5:22 PM, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> > A->B) Dependencies are determined by running Build.PL
> >
> > B->A) Build.PL has a dependency on Module::Build.
> >
> &
On 13/12/2007, Michael G Schwern <[EMAIL PROTECTED]> wrote:
>
> Adam Kennedy wrote:
> > But I'll note that the pass-through Makefile.PL is required to allow for
> > installation on default installs from any Perl distribution 5.8.8 or
> older
> > (due to
The others have answered your question.
But I'll note that the pass-through Makefile.PL is required to allow for
installation on default installs from any Perl distribution 5.8.8 or older
(due to a long-standing circular problem that prevents auto-upgrading).
5.10.0 will support the current Modul
1 - 100 of 153 matches
Mail list logo
