* Lunch one of the three days if we want to timebox the discussion a bit
more.
Of these, Monday evening seems "safest" in terms of having the fewest
variables and greatest opportunity for length discussion or experimental
coding, but I'm around for any of these, so I'm open to any option.
Regards,
David Golden
Bummer that Ken and Randy can't make it. Still, since the conversation
is starting here, lets try to get preliminaries out of the way so any
time at YAPC can be focused on key issues.
Ken Williams wrote:
build_requires:
Module::Build(C_support): 0.28
Ick. If we go that route, I'd rathe
Ken Williams wrote:
A generalized feature dependency scheme is actually what I meant. The
general syntax (subject to review, of course) would be
MODULE(FEATURE1,FEATURE2,...): VERSION
What were you thinking in terms of how modules would describe what
features they provide?
David
Nicholas Clark wrote:
So how do I install Module::Build?
Isn't this a classic circular dependency problem:
* M::B >= 0.2802 requires version 0.64
* version 0.64 requires M::B through its Makefile.PL
Maybe M::B needs to bundle version.pm with it. Or we need to find a way
for version.pm to i
them as normal?
Regards,
David Golden
Eric Wilhelm wrote:
But, I'm guessing from the response to my proof-of-concept that there
isn't any interest in bundling here.
Somewhere along the line on one list or another, John mentioned that he
got version.pm switched over to a regular Makefile.PL that uses EU::MM.
So we are free of the
John Peacock wrote:
David Golden wrote:
[cc'd to perl-qa for awareness of the issue]
The switch to version objects in Module::Build means that the generated
META.yml now has this:
Is this with or without YAML itself loaded (so I know where to start)?
Sorry about that:
YAML 0.62
M
Ray Zimmerman wrote:
Btw, the Module::Build list moved from
[EMAIL PROTECTED] to module-build@perl.org
Shouldn't somebody disable the old list?
Disable it in my email address book, you mean? :-)
What's that acronym about the problem being in front of the keyboard?
Thanks for the reminder.
John Peacock wrote:
David Golden wrote:
[cc'd to perl-qa for awareness of the issue]
The switch to version objects in Module::Build means that the generated
META.yml now has this:
Is this with or without YAML itself loaded (so I know where to start)?
I did a little digging and this
Steffen Mueller wrote:
John Peacock schrieb:
David Golden wrote:
(Though technically, it really ought to check that the ref equals
"Module::Build::Version").
No, that would be wrong too. Never test a ref() against a specific
object
class, since it paints you into a corner with i
ather than having it try to bootstrap
itself. I suspect that it would make upgrading M::B much easier and
allow modules that depend on M::B to specify versions of M::B that they
rely upon without self-upgrade problem that Adam Kennedy keeps pointing out.
Essentially, everything would be EU::MM until M::B is installed.
Food for thought.
Regards,
David Golden
demerphq wrote:
On 7/22/06, David Golden <[EMAIL PROTECTED]> wrote:
2) The Complex Problem: Dual XS/PP modules are not hard to do (e.g.
Params::Validate), but they do require robust compiler detection across
platforms,
Im a little confused about this one. I can think of a few module
Nicholas Clark wrote:
On Sun, Jul 23, 2006 at 09:37:00AM -0400, David Golden wrote:
system( "$Config{cc} -o test$Config{obj_ext} test.c" )
Which, as a fall-back, is hopefully a bit more portable. Frankly, I'm
not sure why it isn't just "$Config{cc} test.c", bu
r a fix or can
it be fixed immediately by installing version.pm X.YY?
Regards,
David Golden
Ken Williams wrote:
Hmm. Is there some way that we could test new releases in several
combinations of platform/perl-version/installed-modules environments?
I would LOVE that.
http://ali.as/pita/
I think some progress was made at the YAPC hackathon. Adam would have
to give a more complete
John Peacock wrote:
version: 0.61.129
version: v0.61.129
Personally I'm thinking the former but I'm not sure.
The version object code understands both to be the same value (i.e. with
or without leading 'v'). The normal form for version objects is with
the leading 'v', which is wha
John Peacock wrote:
FWIW, Andreas already augmented PAUSE and the CPAN indexer to use
version.pm (almost a year ago, when I noticed that TheDamian was
recommending version objects in PBP). What other parser of META.yml are
you concerned with?
E.g. CPAN.pm and Module::CPANTS::Analyse. (Based
d CPAN as an explicit prerequisite, which
happened at version 1.88. I'm on Strawberry Perl 5.8.8 with M::B 0.2805 and
version.pm 0.6701.
The error string is in Module::Build::ModuleInfo but I haven't had a chance
to figure out why CPAN.pm is triggering it.
Regards,
David Golden
On 10/18/06, Ray Zimmerman <[EMAIL PROTECTED]> wrote:
> I'm not sure if this is an issue in CPAN or in M::B.
Actually, I just tried another machine with CPAN-1.87 and it worked
fine. When I upgraded to CPAN-1.8801 it gave me the same error. So
are the CPAN folks listening here? If not, where sho
On 1/22/07, Sendu Bala <[EMAIL PROTECTED]> wrote:
I'm not sure that particular warning to 'fancy developers' makes much
sense. At least not to me, and I suppose its directed specifically at
me. In fact the creation of _build/prereqs is slightly magical; I never
even realised the file was being cr
On 1/28/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
I realized that 'perl Build.PL' doesn't return a failure exit status
when dependencies are missing. Do CPAN/CPANPLUS not check this?
For CPAN.pm, it may or may not check the exit status:
* If the system supports $SIG{ALRM} and there's an ina
I've had some requests for a mechanism for module authors to indicate
whether or not they want to be copied on module test emails generated
by CPAN::Reporter (particularly for passing reports). This seems like
the kind of thing that should go in the module META.yml.
Is there a de facto standard
On 3/9/07, Andreas J. Koenig <[EMAIL PROTECTED]> wrote:
Sure can we. If you would let the user use his terminal the way it was
designed. STDIN closed means: there's nothing to expect. User can do
this by "< /dev/null". Because we want to support more than one way:
PERL_MM_USE_DEFAULT=1 is the sec
On 3/9/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
If Module::Build is about making perl programs easier to install in more
places, I don't think having Build.PL behave with the manners of
find/grep/rm is the way to achieve that. Weigh the effort of trying to
walk somebody through a Build.PL via
On 5/21/07, John Peacock <[EMAIL PROTECTED]> wrote:
I received a complaint against my SVN::Notify::Build distro:
https://rt.cpan.org/Public/Bug/Display.html?id=27183
that has me annoyed. I provide a compatibility Makefile.PL so that
users without Module::Build installed will get bootst
On 5/21/07, John Peacock <[EMAIL PROTECTED]> wrote:
Austin Schutz wrote:
> What is the point of the compatibility file if it requires
> Module::Build to work correctly?
But the compatibility file *itself* doesn't require Module::Build - it
merely checks to see whether it M::B is installed
Module::Build::Compat drops 'perl' from the list of prerequisites when
generating a Makefile.PL and/or Makefile. While EU::MM doesn't handle
'perl' well (it issues a warning about a missing prerequisite), it
does still write it into the Makefile PREREQ_PM line and into the
META.yml.
By dropping
On 7/19/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
The way MakeMaker traditionally handles a perl prerequisite is by sticking
"require 5.xxx" at the top of the Makefile.PL. The CPAN tools can spot the
resulting error message and take the appropriate action.
Is this documented anywhere?
On 7/19/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
# from David Golden
# on Wednesday 18 July 2007 09:05 pm:
>While EU::MM doesn't handle
>'perl' well (it issues a warning about a missing prerequisite), it
>does still write it into the Makefile PREREQ_
On 7/19/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Yeah, well, that's what we've got. Its written down on the CPAN testers wiki
and I also confirmed it with Barbie at YAPC.
"Making distributions CPAN Testers friendly"
http://cpantest.grango.org/cgi-bin/pages.cgi?act=wiki-page&pagename=CPA
On 7/20/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
>I think that would be excellent and would eliminate the need for
>EU::MM to do special handling for 'perl'. (Well, maybe it should in
>case people writing Makefile.PL themselves don't realize they
>shouldn't use 'perl'.)
Well, EU::MM *cannot*
On 7/19/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
>The way MakeMaker traditionally handles a perl prerequisite is by
> sticking "require 5.xxx" at the top of the Makefile.PL.
That's what I was fishing for.
I think we want to keep the current behavior, but print 'require' in the
Makfile.PL.
On 7/21/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Are you suggeting that ExtUtils::MakeMaker go into Bundle::CPAN? That's a
very good idea.
It's not?!? I always assumed it was since M::B was there. (In fact
I just checked and it's there now, but that sneaky Andreas just
released a ne
doesn't support it anyway.
Comments and critiques welcome.
Regards,
David Golden
M-B-Compat-require-perl.patch
Description: Binary data
On 7/23/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > Are you suggeting that ExtUtils::MakeMaker go into Bundle::CPAN? That's a
> > very good idea.
While we're at it, ExtUtils::Install, ExtUtils::Command and
ExtUtils::Manifest. Though ExtUtils::MakeMaker ships with a set that works.
On 7/26/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> >The issue
> >is in process_PL which calls run_perl_script without checking the
> >return value:
>
> Is this already in RT? It sounds familiar.
Apparently so!
https://rt.cpan.org/Ticket/Display.html?id=26931
and with a trivial patch, no less
I was creating a small test distribution to see how some additions to
CPAN::Reporter handle failures during "make" or "perl Build". My
approach was to specify a PL file that just dies immediately.
The EU::MM Makefile interprets that as a make failure and returns a
non-zero exit code. However, t
I thought that was what "build_requires" was for. I seem to recall
some discussion that it was supposed to be everything up to actual
installation and that further granularity with uncertain benefit, but
a lot of toolchain support changes, wasn't a priority.
Regards,
David
On 7/31/07, Eric Wilhe
On 8/14/07, Ken Williams <[EMAIL PROTECTED]> wrote:
> One might have noticed that a couple weeks ago I checked in some code
> in the M::B repository called inc/latest.pm . The idea is to allow
> users to put a bundled copy of M::B in their distribution so that
> their users don't have to have it p
On 8/22/07, wu-lee <[EMAIL PROTECTED]> wrote:
> I've written a module which is essentially an application.
>
> As such, it needs to install some config files, templates, and web
> content. These need to have permissions and ownership set appropriately
> for the host system (which might not be unix)
On 9/21/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Michael G Schwern wrote:
> Hmm. I just noticed that I set 'no_index' for the src directory which
> contains the SVN:: modules which brings up the interesting question of which
> takes precedence, no_index or provides?
>
> Since provides is
On 9/22/07, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Here's the problem. "no_index" allows me to blot out whole directory trees
> and individual files. "provides" allows me to specify individual files.
But the two keys do different things.
"provides" maps a package name to a filename and,
On 9/22/07, Ken Williams <[EMAIL PROTECTED]> wrote:
> My understanding is that "no_index" is only useful when "provides"
> isn't there and an indexer has to guess what you provide. When
> "provides" is there, it should be exhaustive. Note that the spec
> says "indexers will usually trust the C fi
ot;NA" grade.
I welcome thoughts on these suggestions or other suggestions to make
M::B and CPAN::Reporter play nicer with older versions of Perl.
Sincerely,
David Golden
On 10/27/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> # from David Golden
> # on Saturday 27 October 2007 12:24:
>
> >1) M::B should probably be patched to check for a perl version
> >requirement before it tries to eval any code from anything in the
> >distribut
On 10/27/07, Eric Wilhelm <[EMAIL PROTECTED]> wrote:
> I think we should take this as an opportunity to consider how many
> redundancies are "suggested" for Build.PL "for the sake of
> compatibility."
>
> http://www.nntp.perl.org/group/perl.module.build/2007/09/msg902.html
>
> The publishing auth
On 10/28/07, Thomas Klausner <[EMAIL PROTECTED]> wrote:
> So, is META.yml to strict (i.e. should author be a list or a string)?
> Is Test::YAML::Meta::Version to strict?
> Is this just a bug in Module::Install and has to be fixed there?
IMHO, a spec is a spec. If the next version of the spec says
On 10/29/07, Ken Williams <[EMAIL PROTECTED]> wrote:
> On Oct 28, 2007, at 4:54 PM, Ron Savage wrote:
> > From my point of view, as a module author, the spec has the bug in it.
>
> Yet look what happens to everyone's parsing tools when we change the
> spec in the name of "convenience":
> [snip]
>
On Nov 17, 2007 11:30 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Let's put it on it's head. We control META.yml. META.yml consumers have to
> write special code to handle "requires: perl" anyway. What's the advantage of
> doubling up the meaning of "requires"? It didn't take advantage o
On Nov 18, 2007 9:27 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> David Golden wrote:
> > So, yes, it was a crappy design decision/hack, but now we're stuck with it.
>
> No, we should not wedge ourselves into a corner like this. Preventing a
> better way
[Whoops -- somewhere along the line Adam and I stopped CC'ing the
list. I'd meant my reply to go to all, so I'm forwarding it below.]
On Nov 19, 2007 8:10 AM, David Golden <[EMAIL PROTECTED]> wrote:
> On Nov 19, 2007 3:12 AM, Adam Kennedy <[EMAIL PROTECTED]> wrote:
On Nov 19, 2007 9:01 AM, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> > We've probably spent more time debating this issue than it would have
> > taken to apply the patch and write perl.pm.
> >
>
> And with good reason, because there's likely to be secondary impacts from
> this we have not considered
On Nov 20, 2007 8:40 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> I also note that every other installer in the universe, the very first thing
> it does, is it updates the installer. It is usually not an optional thing for
> just the sort of chicken/egg problems we worry about. That we lea
On Nov 24, 2007 1:30 PM, demerphq <[EMAIL PROTECTED]> wrote:
> Personally I think that this is an incredibly elegant and clever
> solution. Im surprised you dislike it so much. It seems to me that if
> it also somehow exposed the perl build number (aka .patch number) then
> it would be quite useful
Your modules probably define their version with "our $VERSION" -- that
blows up on 5.005 when EU::MM or M::B try to evaluate the line they
parse out of your code. If you put "use 5.006" at the top of your
Makefile.PL or Build.PL, you'll be much friendlier to anyone who tries
to run your code on 5.
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.
>
> The code used to determine dependencies itself has a critical dependency it
> can't work without.
Didn't this get fixed
On Dec 12, 2007 8:56 PM, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> The problem is NOT that Module::Build can't install itself.
>
> The problem is that nobody that USES Module::Build can declare a dependency
> on it.
Right. That problem. You lost me in the example.
configure_requires is one step
On Dec 13, 2007 7:59 AM, Adam Kennedy <[EMAIL PROTECTED]> wrote:
> > 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
On Dec 22, 2007 8:02 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> >> version:2.01
> >> api_version:2.0
> >> api_compatibility: 1.4
> >> stability: high
> >> release_type: bugfix
> >>
> >> What this would communicate is that this is versi
On Jan 23, 2008 10:21 PM, Ken Williams <[EMAIL PROTECTED]> wrote:
> The original idea from Adam was to automatically add
> configure_requires => {M::B => $M::B::VERSION} to every M::B-using
> distro, but we don't do that at this point.
Nor should we. For most distributions, having Module::Build c
On Jan 24, 2008 1:33 PM, David E. Wheeler <[EMAIL PROTECTED]> wrote:
> Module::Build can recognize when it is asked to create such a
> Makefile.PL and not automatically include itself in config_requires.
> Otherwise, I agree with Adam that it probably ought to, perhaps just
> defaulting to 0.28.
T
On Jan 24, 2008 4:19 PM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Not much point, CPAN.pm will already install Module::Build when it detects a
> Build.PL.
Wow! I missed that one. And I usually try to read the Changes in
CPAN, too. Well, that was a good decision.
David
On Jan 29, 2008 12:56 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> 2) The most common mistake is forgetting about dependent actions when you do
> a complete override, and that's not documented anywhere.
Sure it's documented -- it's documented in the code. I can't imagine
doing a complete o
On Jan 29, 2008 3:44 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> Module::Build. I prefer the descriptive local_chdir() over the very Unixy and
> cryptic pushd().
Maybe I should add that as an alias in the next release.
David
On Feb 19, 2008 2:49 AM, Jan Dubois <[EMAIL PROTECTED]> wrote:
> I've been wondering if a Bundle::* distribution on CPAN should list
> all the modules specified in the CONTENTS section of the module
> also in the "requires" section of META.yml. Obviously the CPAN
> shell doesn't require this, as n
On Wed, Feb 27, 2008 at 6:52 PM, Elliot Shank <[EMAIL PROTECTED]> wrote:
> Just stop using Bundles. Create Task:: distributions instead. No funky
> handling necessary.
Can Task:: distributions cause the installer to upgrade to the latest
version of a module? I.e. the way we can install Bundle
On Thu, Feb 14, 2008 at 3:54 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
Sorry -- just catching up on this thread.
> > {
> >$dir->local_chdir();
> >...do your stuff...
> > }
> >
> > but that's probably out of my ken.
Subroutine prototype?
$dir->do_within {
};
Also -- feel
On Thu, Feb 28, 2008 at 12:07 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> David Golden wrote:
> > Can Task:: distributions cause the installer to upgrade to the latest
> > version of a module? I.e. the way we can install Bundle::CPAN to get
> > upgrades of a
On Thu, Feb 28, 2008 at 3:20 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> > I was sort of being rhetorical. My point was that Bundles are
> > semantically different than distributions. They are equivalent to
> > stringing a whole bunch of modules or distributions together on the
> > cpa
On Thu, Feb 28, 2008 at 11:47 PM, Christopher J. Madsen <[EMAIL PROTECTED]>
wrote:
> As I was about to check in these changes, I realized that's the wrong
> way to do it. I want these features in all my modules, and I don't want
> to have to copy & paste them into My_Build subclasses. And I'l
On Fri, Feb 29, 2008 at 1:04 PM, Ken Williams <[EMAIL PROTECTED]> wrote:
> Keep in mind that the only easy use case for it is for build_requires
> stuff. True runtime requirements ought to still be fetched from CPAN
> as per usual.
Nit: also for configure_requires.
David
On Fri, Mar 7, 2008 at 1:25 PM, John Peacock <[EMAIL PROTECTED]> wrote:
> OK, I give up. How to I communicate to the CPAN testing framework that
> the test machine is missing a required/vital external binary and should
> just NA this test? I've replicated the way that the code itself
> searche
On Fri, Mar 7, 2008 at 1:34 PM, Jan Dubois <[EMAIL PROTECTED]> wrote:
> The magic string is:
>
> die "OS unsupported\n";
>
> It is a bit misleading, but those are the magic words to give you an NA
> result.
A missing dependency shouldn't be flagged as NA -- that's supposed to
be only for Perl
On 07 Mar 2008 23:12:30 +0100, Johan Vromans <[EMAIL PROTECTED]> wrote:
> "David Golden" <[EMAIL PROTECTED]> writes:
>
> > A missing dependency shouldn't be flagged as NA -- that's supposed to
> > be only for Perl or architecture incomp
On Tue, Mar 25, 2008 at 12:22 PM, David Carmean <[EMAIL PROTECTED]> wrote:
> My present project is just a script, no libraries/modules, which needs
> to munge a set of files. I need to copy some initial files into a working
> directory, have the script modify them and create some new files, and
For whatever reason, I think it's assuming that "Build.PL" is a PL
file to create during "make". Perhaps particularly old versions of
EU::MM don't exclude Build.PL.
I notice that my generated Makefile.PL files all have this line:
'PL_FILES' => {}
I suspect that keeps older EU::MM from thinking
On Tue, May 20, 2008 at 2:41 PM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> # from Thomas Klausner
>>The general opinion was that three *requires are enough, especially as
>>testing seems to be seen as an integral part of the build process.
>
> This is the opinion of a QA get-together, so I'll guess
On Tue, May 20, 2008 at 11:03 PM, Adam Kennedy
<[EMAIL PROTECTED]> wrote:
> 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 leverage configure_requires:
+1
Reminds me I need to
On Wed, May 21, 2008 at 12:20 AM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> Taking 'test_requires:' as an example, note that any older installer
> will not be looking at that key and the tests will fail, so one would
> have to list those prereqs in 'requires:' for backward compatibility,
> but then
On Wed, May 21, 2008 at 9:25 PM, Ken Williams <[EMAIL PROTECTED]> wrote:
> On Tue, May 20, 2008 at 11:31 PM, Adam Kennedy
> <[EMAIL PROTECTED]> wrote:
>>
>> That said, it's possible that we might be able to fix this problem with
>> METALOCAL.yml...
>
> Wuzzat?
At Oslo, there was strong consensus t
On Fri, Jun 20, 2008 at 11:56 AM, Michael G Schwern <[EMAIL PROTECTED]> wrote:
> chorny has patched MakeMaker to add build and configure_requires support,
> but realized that the 1.3 META.yml spec doesn't have configure_requires.
> That's only in the bleading version. I don't want to release a Ma
On Tue, Jun 24, 2008 at 1:33 AM, Jan Dubois <[EMAIL PROTECTED]> wrote:
> I don't think it needs to be in 1.4, but it would be good to explicitly
> declare the special status of the "perl" key in the requires section.
> The synopsis of the spec indicates that you are supposed to be able to
> specify
On Tue, Jun 24, 2008 at 11:55 AM, David E. Wheeler <[EMAIL PROTECTED]> wrote:
> On Jun 24, 2008, at 03:42, David Golden wrote:
>
>> That's a great point. The Oslo Consensus (from the Oslo QA hackathon)
>> agreed on supporting 'perl' as a special key for requi
On Tue, Jul 8, 2008 at 7:57 PM, Ron Savage <[EMAIL PROTECTED]> wrote:
> In my Build.PL I have:
> requires =>
> {
> Carp=> 0,
> perl=> '5.005_62',
> XML::Parser => 0,
> XML::Records=> 0,
> XML::TokeParser => 0,
> },
> which a
On Wed, Jul 9, 2008 at 9:05 AM, Ted Zlatanov <[EMAIL PROTECTED]> wrote:
> Lingua::Slavic::Numbers
> Lingua::BG::Numbers (requires Lingua::Slavic::Numbers but does not use
> inheritance)
> (plus other Lingua::LL::Numbers for LL in (RU SR etc.))
>
> Tests in t/ exercise both modules listed above.
>
On Thu, Jul 10, 2008 at 4:10 AM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> Any testers want to run a few weeks worth of smokes against it? I'm not
> sure if anyone is setup to do that. e.g. for any clean-smoke
> environment - your smoker needs to install the alpha M::B when it sees
> it as requir
On Thu, Jul 10, 2008 at 12:32 PM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> Any chance we could use a transfer protocol other than e-mail? Was
> there some progress on an HTTP POST mechanism for this?
Yes, actually, that's a good idea.
Test::Reporter::Transport::HTTPGateway -- it was intended to
Can anyone point me at some distros that use M::B::Compat modes?
I want to see what signature strings I can grep for to pick out
Module::Build related test reports even when CPAN is calling
Makefile.PL.
Thanks,
David
On Tue, Jul 15, 2008 at 11:22 PM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> # from Ken Williams
> # on Tuesday 15 July 2008 20:10:
>
>>> How horribly bizarre. We don't even use Devel::Autoflush anywhere.
>>> Maybe it's some Test:: module barfing?
>>
>>Actually, suspiciously, CPAN::Reporter seems t
On Wed, Jul 16, 2008 at 7:10 AM, Andy Armstrong <[EMAIL PROTECTED]> wrote:
> Ah - that'll be the problem with mod_perl2 - apxs is written in Perl and
> uses sysperl.
I have some new ideas for how to make PERL5OPT="-MDevel::Autoflush"
more friendly for multi-perl environments.
Let me try to get a
Andy -- please give this a try with mod_perl2 when your mirror syncs up.
David
-- Forwarded message --
From: PAUSE <[EMAIL PROTECTED]>
Date: Wed, Jul 16, 2008 at 9:53 AM
Subject: CPAN Upload: D/DA/DAGOLDEN/CPAN-Reporter-1.16_50.tar.gz
To: David Golden <[EMAIL PROTECTE
On this thread, Eric asked how to run a "scientific" style test.
Here's an idea based on CPAN Testers tools -- though not necessarily
CPAN Testers output.
a) Configure CPAN::Reporter to use the Test::Reporter::Transport::File
transport -- this will save reports into a directory
b) Run CPAN::Repo
On Thu, Sep 11, 2008 at 11:16 PM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> * unfortunately I did notice that this included Sub::UpLevel, and there
> was rather a large thread about that today which I didn't read. I
> hope that hasn't screwed things up.
That was a Sub::Uplevel bug and has been
On Fri, Sep 12, 2008 at 12:06 PM, David E. Wheeler <[EMAIL PROTECTED]> wrote:
>> Do we need to hand out more commit bits or candy or what?
>
> Yes, once there is adequate test coverage.
Handing them out might help improve coverage.
-- David
I'm recreating my Windows smoker with a fresh copy of Strawberry and
installing the bleeding edge of major toolchain modules. (CPAN,
EU::MM, Test::More, T::H, etc.)
Should I install M::B now from svn or wait for a CPAN dev? I can just
imagine authors bitching at me for things not working with an
On Thu, Sep 18, 2008 at 12:27 PM, David E. Wheeler <[EMAIL PROTECTED]> wrote:
> Can you use the svn copy and not send test results, just to see what
> happens?
Sure. I can just save them to files with
Test::Reporter::Transport::File, but as Eric (?) pointed out, that
doesn't really give us an eas
On Fri, Sep 19, 2008 at 3:15 AM, Eric Wilhelm
<[EMAIL PROTECTED]> wrote:
> Arr, she has left the dock.
>
> We'll give her a right three days or four nights to bob in the harbor
> afore we run the jolly 0.3 up the mainstaff and weigh anchor for the
> high seaPANs.
Fails to install on Strawberry 5.1
After a day of smoking (and only 3 hangs), the count is 350 pass, 20
fail, 20 unknown and 89 discarded (prereq fails).
I don't know how many are Module::Build modules, though. But nothing
looks obviously wrong so far.
I'm going to update my smoker to take a distribution list and look for
the lis
MAIL PROTECTED]>
Date: Sat, Sep 20, 2008 at 10:14 AM
Subject: CPAN Upload: D/DA/DAGOLDEN/CPAN-Reporter-Smoker-0.17.tar.gz
To: David Golden <[EMAIL PROTECTED]>
The uploaded file
CPAN-Reporter-Smoker-0.17.tar.gz
has entered CPAN as
file: $CPAN/authors/id/D/DA/DAGOLDEN/CPAN-Reporter-S
FWIW, I'm running a direct comparison of 0.2808_01 against 0.2808_05
against Eric's list of distributions using Module::Build. (Perl
5.10.0 on linux) The _01 run finished this morning and the _05 run
should finish some time tomorrow. (There are about 2000 more reports
to generate and the smoker
1 - 100 of 416 matches
Mail list logo
