module-build-general — General discussion about Module::Build project

Re: [Module::Build] ask() and you will receive

[David W. <da...@ki...>]

On Apr 10, 2006, at 01:25, Randy W. Sims wrote:

> Thanks! There are some usefull ideas here. I'll probably keep  
> things simple for the 0.28 release, but I definately see things  
> like tieing it into the new options in the next release.

I found the environ option very useful for, e.g., PostgreSQL settings.

> Might possibly go ahead and add the callback; this very much echos  
> the options interface. It has a multi-option type, and callbacks  
> via the on_validate handler. OTOH, the user could do this via.
>
> my $need_answer = 1;
> while ($need_answer) {
>   my $ans = $mb->ask(...);
>   $need_answer = !valid_answer( $ans );
> }
>
> So a handler only adds a little bit of sugar...

Yes, but it's cleaner to use a callback, at least from the user's  
point of view.

Best,

David

Re: [Module::Build] Preserving files' executable bits, once more

[Ray Z. <rz...@co...>]

On Apr 10, 2006, at 3:04 AM, Randy W. Sims wrote:
> Ken Williams wrote:
>> On Apr 8, 2006, at 11:17 PM, Randy W. Sims wrote:
>>>
>>> Borrowing code from ExtUtils::Install::install() and ::pm_to_blib  
>>> (), the copy_if_modified() method now preserves file mode and   
>>> timestamps.
>> Sounds good to preserve mode, but I'm not sure we want to  
>> preserve  timestamps.  Seems like the timestamp can be a useful  
>> indicator of  when a file got updated.
>
> Hmm, I hadn't really thought too much about it. I was copying the  
> behavior of MakeMaker via ExtUtils::Install, basically copying the  
> code verbatim from there. I'm not sure too many people would argue  
> it either way though.
>
> I'll go ahead and back out the timestamp change if there are no  
> arguments.

I think I would have a slight preference to preserving timestamps as  
well. Unfortunately, there are probably conflicting conventions here  
for different platforms/installers etc. I'm probably just used to Mac  
OS where moving and copying files around does not typically touch  
their timestamps. But again different installers probably handle that  
differently, even on Mac OS.

	Ray

Re: [Module::Build] Capturing test output to please CPANPLUS

[Jos I. B. <ka...@xs...>]

On Apr 10, 2006, at 8:46 AM, Randy W. Sims wrote:

> Randy W. Sims wrote:
>> Will something like this work for a temporary solution that we can  
>> maybe figure out how to extend in the future to always capture  
>> output?
>
> Regarding Ticket #9793 [1]
>
> Scratch that. I don't really like my previous solution. I'm not  
> sure Module::Build needs to be responsible for capturing output; I  
> can't really see any benifit.

Well as an API to a build interface, it would be nice to get the  
diagnostics back from that
API, without having to rely on retie'ing STDOUT in your client  
application -- not just CPANPLUS
will want to use this API, but every coder (else, why bother with an  
API?).

The point is that you have the data available at a very precise  
location in M::B, and all you
need to do is store it, and every user can happily use it -- make an  
accessor called ->stack()
with all your 'extra' messages? a specific one called ->test_output?;  
it's all the same to
the user, as long as it doesn't get thrown away!


> Is there a reason CPANPLUS (or CPANPLUS::Dist::Build) can't do  
> this, like below (borrowing again from Jos' patch), or are there  
> other issues I'm not aware of?

It would have to be in CPANPLUS::Dist::Build (which is under the  
module-build group care now
as well) -- It's not an elegant solution, and might break if you  
change any of the internals
of M::B (or test::harness), but it beats not having any output at  
all, since this renders test
reports sent to testers.cpan.org for authors who use M::B quite  
useless :(

> use Module::Build;
> my $mb = Module::Build->new_from_context;
> $mb->dispatch('build');
>
> my $out = '';
> {
>     require IO::String;
>     local *STDOUT;
>     my $io = tie( *STDOUT, 'IO::String' );
>     eval { $mb->dispatch('test') };
>     $out = $io->string_ref;
> }
>
> print $$out;
> die $@ if $@;
>
>
> 1. <http://rt.cpan.org/Public/Bug/Display.html?id=9793>

--
	Jos Boumans

	"Two rules to success in life:
   	1. Don't tell people everything you know"
		--Sassan Tat

	CPANPLUS	http://cpanplus.sf.net

Re: [Module::Build] Fwd: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[demerphq <dem...@gm...>]

On 4/10/06, Randy W. Sims <ml...@th...> wrote:
> demerphq wrote:
> > On 4/10/06, Randy W. Sims <ml...@th...> wrote:
> >>It's a bug in Archive::Tar that we were not able to resolve with the
> >>maintainer. The directories are there, but some Windows programs can't
> >>see them: WinZip, older versions of WinRAR, etc. GNU tar on *nix and
> >>Cygwin can read them. The newest WinRAR can. Maybe 7-zip?
> >
> >
> > Ok it didnt occur to me it might be a problem with winzip, so ill
> > investigate using other tools. I also noticed that the tar/gzip
> > produced by EUMM was about 5-10k smaller. But IMO having a problem
> > with Winzip is a pretty big problem. :-)
>
> Yup.

Maybet MB should probe for tar and if its found use it on win32 as a
preference? Most people doing module release on Win32 will have tar
installed IMO, one way or another.


> Is there a tar program that works on Windows? I've tried quite a few but
> could find any that could /create/ an archive on Windows, other than
> with Cygwin.
>
> perl Build dist --tar C:\bin\tar.exe --gzip C:\bin\gzip.exe

Ok. Well thats simple.  Ill play around with it and see whats up.

And regarding tar/gzip i use the cygwin ones. They work fine from
cmd.exe. Ive also used other ports and they worked ok too. But I tend
to stick to cygwin ones.

Although i do recall that one trick with using them from cmd.exe is to
use relative paths only, ie cd into a directory such that you can do a
relative path.

> >>I don't know how to resolve this issue. Since Archive::Tar is now in
> >>perl core, it may be worth bringing up there? Other tar programs, like
> >>GNU tar, create archives that work correctly in any archive tool.
> >
> >
> > Once i understand the problem I definately will bring it up with the
> > maintainers. Im pretty sure this wasnt a problem in older versions.
>
> <http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/282/>
> <http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/677/>

Oooh. Big threads. :-) Ill have to review them.

> >>>So all I did was a
> >>>
> >>>  nmake dist
> >>>
> >>>So regarding the executable bits being set, my assumption is that
> >>>tar/gzip when run from the cmd.exe shell gets permissions wrong?
> >>
> >>I never really noticed this before. Will have to check into it. Windows
> >>doesn't have equivelant file modes, but I would expect it to err on the
> >>side of leaving the executable bit unset...
> >
> >
> > Ive not noticed it specifically either, but that doesnt mean anything.
> > I have experienced _general_ odd problems with unpacking files
> > sometimes. Some compression tools manage to pack the files so when i
> > unpack them they have Win32 ownership rights for people who arent
> > registered on my machine, meaning i have to retake ownership of them
> > before I can use them, ive also seen odd attributes being applied for
> > no apparent reason. Ive never bothered to look into it deeper than how
> > to override the problem tho.
>
> I'll need to investigate this at some point for Module::Build. See what
> happens when dist is run on Windows...

Well, I checked my Archive::Tar version and apparently its up to date.
So at this point on my .27 patched I have a problem with the dist
creation.

Yves

--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] ask() and you will receive

[Randy W. S. <ml...@th...>]

David Wheeler wrote:
> On Apr 8, 2006, at 03:32, Randy W. Sims wrote:
> 
>> my $answer;
>> $answer = Prompter->ask(
>>     prompt  => "What is your favorite programming language?\n",
>>     options => [qw(Perl Ruby Lua Python C C++)],
>>     default => 'unknown',
>>     show_options => 1,
>>     show_default => 0,
>> );
>>
>> print "Answer: $answer\n";
> 
> 
> This actually looks similar to a method I wrote in my subclass. I  think 
> that you might find my "environ" and "callback" options useful  additions:

Thanks! There are some usefull ideas here. I'll probably keep things 
simple for the 0.28 release, but I definately see things like tieing it 
into the new options in the next release.

Might possibly go ahead and add the callback; this very much echos the 
options interface. It has a multi-option type, and callbacks via the 
on_validate handler. OTOH, the user could do this via.

my $need_answer = 1;
while ($need_answer) {
   my $ans = $mb->ask(...);
   $need_answer = !valid_answer( $ans );
}

So a handler only adds a little bit of sugar...

Randy.

Re: [Module::Build] Fwd: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[Randy W. S. <ml...@th...>]

demerphq wrote:
> On 4/10/06, Randy W. Sims <ml...@th...> wrote:
>>It's a bug in Archive::Tar that we were not able to resolve with the
>>maintainer. The directories are there, but some Windows programs can't
>>see them: WinZip, older versions of WinRAR, etc. GNU tar on *nix and
>>Cygwin can read them. The newest WinRAR can. Maybe 7-zip?
> 
> 
> Ok it didnt occur to me it might be a problem with winzip, so ill
> investigate using other tools. I also noticed that the tar/gzip
> produced by EUMM was about 5-10k smaller. But IMO having a problem
> with Winzip is a pretty big problem. :-)

Yup.

> And to be honest im not so sure about using Archive::Tar as a first
> option. I recall from previous times looking at it that its horribly
> inefficient when dealing with larger file sizes (possibly this has
> been resolved). IMO it would probably be preferable to let tar do the
> work if its available. Is there some way I can tell MB that i would
> prefer that it use a shell tool instead of pure perl stuff? (Im
> cheating here, as i havent looked at the docs of MB to see if an
> answer is there :-)

Is there a tar program that works on Windows? I've tried quite a few but 
could find any that could /create/ an archive on Windows, other than 
with Cygwin.

perl Build dist --tar C:\bin\tar.exe --gzip C:\bin\gzip.exe

>>I don't know how to resolve this issue. Since Archive::Tar is now in
>>perl core, it may be worth bringing up there? Other tar programs, like
>>GNU tar, create archives that work correctly in any archive tool.
> 
> 
> Once i understand the problem I definately will bring it up with the
> maintainers. Im pretty sure this wasnt a problem in older versions.

<http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/282/>
<http://thread.gmane.org/gmane.comp.lang.perl.modules.module-build/677/>


>>>So all I did was a
>>>
>>>  nmake dist
>>>
>>>So regarding the executable bits being set, my assumption is that
>>>tar/gzip when run from the cmd.exe shell gets permissions wrong?
>>
>>I never really noticed this before. Will have to check into it. Windows
>>doesn't have equivelant file modes, but I would expect it to err on the
>>side of leaving the executable bit unset...
> 
> 
> Ive not noticed it specifically either, but that doesnt mean anything.
> I have experienced _general_ odd problems with unpacking files
> sometimes. Some compression tools manage to pack the files so when i
> unpack them they have Win32 ownership rights for people who arent
> registered on my machine, meaning i have to retake ownership of them
> before I can use them, ive also seen odd attributes being applied for
> no apparent reason. Ive never bothered to look into it deeper than how
> to override the problem tho.

I'll need to investigate this at some point for Module::Build. See what 
happens when dist is run on Windows...

Randy.

Re: [Module::Build] Fwd: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[demerphq <dem...@gm...>]

On 4/10/06, Randy W. Sims <ml...@th...> wrote:
> demerphq wrote:
> > On 4/10/06, Randy W. Sims <ml...@th...> wrote:
> >
> >>Randy W. Sims wrote:
> >>
> >>>demerphq wrote:
> >>>
> >>>
> >>>>Hi All,
> >>>>
> >>>>I am now one of the co-maintainers of ExtUtils-Install, and i have
> >>>>released the first standalone of the distro as ExtUtils-Install-1.38
> >>>
> >>>
> >>>Excellent. Great work on this.
> >>>
> >>
> >>BTW, How did you create the distribution? I notice that every file in
> >>the distribution is set to file mode 0755 on *nix, which is to say that
> >>all the files have the executable bit set. Weird.
> >
> >
> > Actually I wanted to bring a couple of things up with you guys but
> > havent gotten around to it yet.
> >
> > When i tried
> >
> >   build dist
> >
> > the resulting tar.gz contained no paths, all files were in a single
> > flat directory. When i did it with EU::MM the proper tree was created.
> > But im currently using an older beta release of MB so its quite
> > possible this is a bug that has been fixed.
>
> It's a bug in Archive::Tar that we were not able to resolve with the
> maintainer. The directories are there, but some Windows programs can't
> see them: WinZip, older versions of WinRAR, etc. GNU tar on *nix and
> Cygwin can read them. The newest WinRAR can. Maybe 7-zip?

Ok it didnt occur to me it might be a problem with winzip, so ill
investigate using other tools. I also noticed that the tar/gzip
produced by EUMM was about 5-10k smaller. But IMO having a problem
with Winzip is a pretty big problem. :-)

And to be honest im not so sure about using Archive::Tar as a first
option. I recall from previous times looking at it that its horribly
inefficient when dealing with larger file sizes (possibly this has
been resolved). IMO it would probably be preferable to let tar do the
work if its available. Is there some way I can tell MB that i would
prefer that it use a shell tool instead of pure perl stuff? (Im
cheating here, as i havent looked at the docs of MB to see if an
answer is there :-)

> I don't know how to resolve this issue. Since Archive::Tar is now in
> perl core, it may be worth bringing up there? Other tar programs, like
> GNU tar, create archives that work correctly in any archive tool.

Once i understand the problem I definately will bring it up with the
maintainers. Im pretty sure this wasnt a problem in older versions.

> > So all I did was a
> >
> >   nmake dist
> >
> > So regarding the executable bits being set, my assumption is that
> > tar/gzip when run from the cmd.exe shell gets permissions wrong?
>
> I never really noticed this before. Will have to check into it. Windows
> doesn't have equivelant file modes, but I would expect it to err on the
> side of leaving the executable bit unset...

Ive not noticed it specifically either, but that doesnt mean anything.
I have experienced _general_ odd problems with unpacking files
sometimes. Some compression tools manage to pack the files so when i
unpack them they have Win32 ownership rights for people who arent
registered on my machine, meaning i have to retake ownership of them
before I can use them, ive also seen odd attributes being applied for
no apparent reason. Ive never bothered to look into it deeper than how
to override the problem tho.

Yves




--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] ask() and you will receive

[Randy W. S. <ml...@th...>]

Ken Williams wrote:
> I think this is a decent direction.  I only have a couple of  concerns: 
> one, I do think that the default needs to be one of the  options in an 
> option list, or else people are just going to make too  many mistakes.  

I debated that decision for a while. The reason I allowed it was that 
when running an unattended build, none of the choices may be a 
reasonable default. In that case the default can be set to an empty 
string or something that make sense to indicate that no choice was made.

Note also that 'default' may be set to an empty string or to any value, 
including undef as long as something is passed in.

One alternative I can think of:

$answer = Prompter->ask(
     prompt  => "What is your favorite programming language?\n",
     options => [qw(Perl Ruby Lua Python C C++ /unknown/)],
     default => 'unknown',
);

Another element is added to 'options' enclosed between slashes (or 
something). Such elements would not be show when options are displayed. 
Then default can be set to the "invisible" option.

> Two, maybe we can come up with a better name, just  because I don't like 
> classes that end in "er".

Actually, I intended this code to be in Module::Build::Base. I just 
extracted it to make it easy to review. So actual usage would be:

use Module::Build
my $mb = Module::Build->new(...);

$mb->ask(...);

  -or-

Module::Build->ask(...);

Randy.

Re: [Module::Build] Fwd: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[Randy W. S. <ml...@th...>]

demerphq wrote:
> On 4/10/06, Randy W. Sims <ml...@th...> wrote:
> 
>>Randy W. Sims wrote:
>>
>>>demerphq wrote:
>>>
>>>
>>>>Hi All,
>>>>
>>>>I am now one of the co-maintainers of ExtUtils-Install, and i have
>>>>released the first standalone of the distro as ExtUtils-Install-1.38
>>>
>>>
>>>Excellent. Great work on this.
>>>
>>
>>BTW, How did you create the distribution? I notice that every file in
>>the distribution is set to file mode 0755 on *nix, which is to say that
>>all the files have the executable bit set. Weird.
> 
> 
> Actually I wanted to bring a couple of things up with you guys but
> havent gotten around to it yet.
> 
> When i tried
> 
>   build dist
> 
> the resulting tar.gz contained no paths, all files were in a single
> flat directory. When i did it with EU::MM the proper tree was created.
> But im currently using an older beta release of MB so its quite
> possible this is a bug that has been fixed.

It's a bug in Archive::Tar that we were not able to resolve with the 
maintainer. The directories are there, but some Windows programs can't 
see them: WinZip, older versions of WinRAR, etc. GNU tar on *nix and 
Cygwin can read them. The newest WinRAR can. Maybe 7-zip?

I don't know how to resolve this issue. Since Archive::Tar is now in 
perl core, it may be worth bringing up there? Other tar programs, like 
GNU tar, create archives that work correctly in any archive tool.

> So all I did was a
> 
>   nmake dist
> 
> So regarding the executable bits being set, my assumption is that
> tar/gzip when run from the cmd.exe shell gets permissions wrong?

I never really noticed this before. Will have to check into it. Windows 
doesn't have equivelant file modes, but I would expect it to err on the 
side of leaving the executable bit unset...

Randy.

Re: [Module::Build] Fwd: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[demerphq <dem...@gm...>]

On 4/10/06, Randy W. Sims <ml...@th...> wrote:
> Randy W. Sims wrote:
> > demerphq wrote:
> >
> >> Hi All,
> >>
> >> I am now one of the co-maintainers of ExtUtils-Install, and i have
> >> released the first standalone of the distro as ExtUtils-Install-1.38
> >
> >
> > Excellent. Great work on this.
> >
>
> BTW, How did you create the distribution? I notice that every file in
> the distribution is set to file mode 0755 on *nix, which is to say that
> all the files have the executable bit set. Weird.

Actually I wanted to bring a couple of things up with you guys but
havent gotten around to it yet.

When i tried

  build dist

the resulting tar.gz contained no paths, all files were in a single
flat directory. When i did it with EU::MM the proper tree was created.
But im currently using an older beta release of MB so its quite
possible this is a bug that has been fixed.

So all I did was a

  nmake dist

So regarding the executable bits being set, my assumption is that
tar/gzip when run from the cmd.exe shell gets permissions wrong?

Cheers,
Yves

--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] Preserving files' executable bits, once more

[Randy W. S. <ml...@th...>]

Ken Williams wrote:
> 
> On Apr 8, 2006, at 11:17 PM, Randy W. Sims wrote:
> 
>>
>> Borrowing code from ExtUtils::Install::install() and ::pm_to_blib (), 
>> the copy_if_modified() method now preserves file mode and  timestamps.
> 
> 
> Sounds good to preserve mode, but I'm not sure we want to preserve  
> timestamps.  Seems like the timestamp can be a useful indicator of  when 
> a file got updated.

Hmm, I hadn't really thought too much about it. I was copying the 
behavior of MakeMaker via ExtUtils::Install, basically copying the code 
verbatim from there. I'm not sure too many people would argue it either 
way though.

I'll go ahead and back out the timestamp change if there are no arguments.

Randy.

Re: [Module::Build] Fwd: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[demerphq <dem...@gm...>]

On 4/10/06, Randy W. Sims <ml...@th...> wrote:
> demerphq wrote:
> > Hi All,
> >
> > I am now one of the co-maintainers of ExtUtils-Install, and i have
> > released the first standalone of the distro as ExtUtils-Install-1.38
>
> Excellent. Great work on this.
>
> May I belatedly point out another quick patchlet? I've been looking at
> the Module::Build RT queue and found ticket #16188[1] which also exists
> in the MakeMaker queue as ticket #16225[2]. Scwhern's suversion
> repository is down so I can't investigate what led to the current code;
> it looks like a straightfoward fix though...
>
> Thanks,
> Randy.
>
> 1. <http://rt.cpan.org/Public/Bug/Display.html?id=3D16188>
> 2. <http://rt.cpan.org/Public/Bug/Display.html?id=3D16225>

Sure no problem, Ill follow up on this as soon as I can. Thanks for
bringing it to my attention.

cheers,
Yves


--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"

Re: [Module::Build] Fwd: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[Randy W. S. <ml...@th...>]

Randy W. Sims wrote:
> demerphq wrote:
> 
>> Hi All,
>>
>> I am now one of the co-maintainers of ExtUtils-Install, and i have
>> released the first standalone of the distro as ExtUtils-Install-1.38
> 
> 
> Excellent. Great work on this.
> 

BTW, How did you create the distribution? I notice that every file in 
the distribution is set to file mode 0755 on *nix, which is to say that 
all the files have the executable bit set. Weird.

Randy.

Re: [Module::Build] Capturing test output to please CPANPLUS

[Randy W. S. <ml...@th...>]

Randy W. Sims wrote:
> 
> Will something like this work for a temporary solution that we can maybe 
> figure out how to extend in the future to always capture output?

Regarding Ticket #9793 [1]

Scratch that. I don't really like my previous solution. I'm not sure 
Module::Build needs to be responsible for capturing output; I can't 
really see any benifit. Is there a reason CPANPLUS (or 
CPANPLUS::Dist::Build) can't do this, like below (borrowing again from 
Jos' patch), or are there other issues I'm not aware of?

Thanks,
Randy.

use strict;
use warnings;

use Module::Build;
my $mb = Module::Build->new_from_context;
$mb->dispatch('build');

my $out = '';
{
     require IO::String;
     local *STDOUT;
     my $io = tie( *STDOUT, 'IO::String' );
     eval { $mb->dispatch('test') };
     $out = $io->string_ref;
}

print $$out;
die $@ if $@;


1. <http://rt.cpan.org/Public/Bug/Display.html?id=9793>

Re: [Module::Build] Fwd: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[Randy W. S. <ml...@th...>]

demerphq wrote:
> Hi All,
> 
> I am now one of the co-maintainers of ExtUtils-Install, and i have
> released the first standalone of the distro as ExtUtils-Install-1.38

Excellent. Great work on this.

May I belatedly point out another quick patchlet? I've been looking at 
the Module::Build RT queue and found ticket #16188[1] which also exists 
in the MakeMaker queue as ticket #16225[2]. Scwhern's suversion 
repository is down so I can't investigate what led to the current code; 
it looks like a straightfoward fix though...

Thanks,
Randy.

1. <http://rt.cpan.org/Public/Bug/Display.html?id=16188>
2. <http://rt.cpan.org/Public/Bug/Display.html?id=16225>

Re: [Module::Build] ask() and you will receive

[David W. <da...@ki...>]

On Apr 8, 2006, at 03:32, Randy W. Sims wrote:

> my $answer;
> $answer = Prompter->ask(
>     prompt  => "What is your favorite programming language?\n",
>     options => [qw(Perl Ruby Lua Python C C++)],
>     default => 'unknown',
>     show_options => 1,
>     show_default => 0,
> );
>
> print "Answer: $answer\n";

This actually looks similar to a method I wrote in my subclass. I  
think that you might find my "environ" and "callback" options useful  
additions:

=head3 get_reply

   my $value = $build->get_reply(%params);

Prompts the user with a message, and then collects a value from the  
user (if there is a TTY). A number of options can be specified, and  
the method will display a numbered list from which the user to select  
a value. Callbacks can also be specified to ensure the quality of a  
value.

The supported parameters are:

=over

=item message

A message with which to prompt the user, such as "What is your  
favorite color?".

=item name

The name of the Kinetic::Build::Base property or argument stored in  
the Module::Build C<args()> for which a value is sought. Optional. If  
the value was specified on the command-line, the user will not be  
prompted for a value.

=item label

A label for the value you're attempting to collect, such as "Favorite  
color".

=item default

A default value. This will be used if the user accepts the value (by  
hitting) enter or control-D), and will be returned without prompting  
the user if the C<accept_defaults> property is set to a true value or  
if there is no TTY.

=item options

An array reference of possible values from which the user can select.

=item callback

A code reference that validates a value input by a user. The value to  
be checked will be passed in as the first argument and will also be  
stored in C<$_>. For example, if you wanted to ensure that a value  
was an integer, you might pass a code reference like C<sub { /^\d+$/ } 
 >. Note that if the callback sets C<$_> to a different value, the  
revised value is the one that will be returned. This can be useful  
for parsing one value from another.

=item config_keys

An array reference with two values that will be used to look up the  
value in the configuration file specified by the C<path_to_config>  
property. If no config file has been specified, these values will not  
be used. Otherwise, if no value was found in the Module::Build  
runtime parameters or arguments, the configuration file will be  
consulted. The first item in the array should be the name of the  
config file label, and the second item should be the key for the  
value for that label. For example, if you wanted to get at the store  
class, it might appear in the config file like so:

   [store]
   class: Kinetic::Store::DB::Pg

To retrieve that value, set the array reference to ['store', 'class'].

=item environ

The name of an environment variable to check for a value. Checked  
only after the Module::Build runtime parameters and arguments and the  
configuration file have failed to return a value, but before  
prompting the user.

Best,

David

Re: [Module::Build] ask() and you will receive

[Ken W. <ke...@ma...>]

I think this is a decent direction.  I only have a couple of  
concerns: one, I do think that the default needs to be one of the  
options in an option list, or else people are just going to make too  
many mistakes.  Two, maybe we can come up with a better name, just  
because I don't like classes that end in "er".

  -Ken


On Apr 8, 2006, at 5:32 AM, Randy W. Sims wrote:

> Attached is version of the ask() routine discussed earlier to  
> supersede or augment prompt() and y_n(), including pod. I extracted  
> it directly out of my working copy of MB and put it in its own  
> package to make it easier to demo for feedback. It would go in MB  
> along with prompt() and y_n() if we decide to use it.
>
> Here is a sample driver:
>
> use Prompter;
>
> my $answer;
> $answer = Prompter->ask(
>     prompt  => "What is your favorite programming language?\n",
>     options => [qw(Perl Ruby Lua Python C C++)],
>     default => 'unknown',
>     show_options => 1,
>     show_default => 0,
> );
>
> print "Answer: $answer\n";
>
> __END__
>
> Please see `perldoc Prompter.pm` for docs.
>
> Randy.
>
> <Prompter.pm>

Re: [Module::Build] In _backticks(): multi-arg open not accepted by perl5.004 parser

[Ken W. <ke...@ma...>]

I couldn't think of anything clever, so I'm dynamically generating  
that sub from a string at BEGIN{} time now.

  -Ken


On Apr 9, 2006, at 8:09 PM, Ken Williams wrote:

> Unfortunately that doesn't work either.  At runtime, open() won't  
> unroll its arguments into a list, it seems to be using @cmd in a  
> scalar context.
>
> Lemme brainstorm a little bit and see if I can think of something  
> that compiles under 5.5 and runs under 5.6.
>
>  -Ken
>
>
> On Apr 9, 2006, at 12:09 PM, Ken Williams wrote:
>
>> Grr!
>>
>> This patch should fix it, though:
>>
>> @@ -346,7 +346,8 @@
>>    my ($self, @cmd) = @_;
>>    if ($self->have_multiarg_pipeopen) {
>>      local *FH;
>> -    open FH, "-|", @cmd or die "Can't run @cmd: $!";
>> +    unshift @cmd, "-|";
>> +    open FH, @cmd or die "Can't run @cmd: $!";
>>      return wantarray ? <FH> : join '', <FH>;
>>    } else {
>>      my $cmd = $self->_quote_args(@cmd);
>>
>>
>> Committing.
>>
>>  -Ken
>>
>> On Apr 9, 2006, at 12:53 AM, Randy W. Sims wrote:
>>
>>> randys@new-pieria:~/Module-Build$ ~/perl5.005/bin/perl5.00504  
>>> Build.PL
>>>
>>> Too many arguments for open at lib/Module/Build/Base.pm line 355,  
>>> near "@cmd or"BEGIN not safe after errors--compilation aborted at  
>>> lib/Module/Build/Base.pm line 574.
>>> BEGIN failed--compilation aborted at lib/Module/Build.pm line 14.
>>> BEGIN failed--compilation aborted at Build.PL line 10.
>>>
>>>
>>> -------------------------------------------------------
>>> This SF.Net email is sponsored by xPML, a groundbreaking  
>>> scripting language
>>> that extends applications into web and mobile media. Attend the  
>>> live webcast
>>> and join the prime developer group breaking into this new coding  
>>> territory!
>>> http://sel.as-us.falkag.net/sel? 
>>> cmd=lnk&kid=110944&bid=241720&dat=121642
>>> _______________________________________________
>>> Module-build-general mailing list
>>> Mod...@li...
>>> https://lists.sourceforge.net/lists/listinfo/module-build-general
>>
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the  
>> live webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Module-build-general mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/module-build-general
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general

Re: [Module::Build] M::B and no_index

[Ken W. <ke...@ma...>]

On Apr 9, 2006, at 12:26 AM, Randy W. Sims wrote:

>
> I don't see any other way around this if we want to preserve order  
> of @INC correctly. Either we restore the exact contents of @INC  
> when running Build or if we think the @INC is going to have more  
> additions beteen invokations we can do something like in the  
> attached patch.
>
> Any thoughts on this Ken?

Well, we used to indeed set @INC directly, but we stopped doing it in  
December 2004.  Schwern wrote the patch.  The following entries in  
the 'Changes' file are probably relevant:

=================================
0.2608  Wed Jan 26 19:46:09 CST 2005

[...]
- Work around some bad mojo between Fedora Core [with its very long
    @INC] and old versions of Test::Harness [with its propensity to
    compound the number of @INC entries] that produced an "argument
    list too long" error during testing.  [assisted by Ville Skytta,
    David Golden, & Randy Sims]
[...]

0.2607 (Bug fix release in 0.26 series)  Sat Dec 18 14:14:09 CST 2004

- Instead of freezing @INC in the 'Build' script to the value it had
    when Build.PL was run, we now just add those additional values that
    aren't part of the default compiled-in @INC. [Michael Schwern]

- The run_perl_script() method will now propagate any extra entries
    in @INC (such as those added by "use lib" or the -I command-line
    switch) to the subprocess.  This helps situations in which you want
    to tell the subprocess where to find a certain module, for
    instance.  [Michael Schwern]

=================================


Those considerations aside, I'm still of a split mind about this.  On  
the one hand, if you do @INC=(...) you've got a better chance of  
getting things right, but it can feel too rigid for the user who  
wants to change INC on the fly.  On the other hand, if you do push 
(@INC, ...) then you probably mess up the order of INC even relative  
to its original value, but someone can sneak in some extra paths if  
they want to.

Probably @INC=(...) is marginally better, though?

  -Ken

Re: [Module::Build] In _backticks(): multi-arg open not accepted by perl5.004 parser

[Ken W. <ke...@ma...>]

Unfortunately that doesn't work either.  At runtime, open() won't  
unroll its arguments into a list, it seems to be using @cmd in a  
scalar context.

Lemme brainstorm a little bit and see if I can think of something  
that compiles under 5.5 and runs under 5.6.

  -Ken


On Apr 9, 2006, at 12:09 PM, Ken Williams wrote:

> Grr!
>
> This patch should fix it, though:
>
> @@ -346,7 +346,8 @@
>    my ($self, @cmd) = @_;
>    if ($self->have_multiarg_pipeopen) {
>      local *FH;
> -    open FH, "-|", @cmd or die "Can't run @cmd: $!";
> +    unshift @cmd, "-|";
> +    open FH, @cmd or die "Can't run @cmd: $!";
>      return wantarray ? <FH> : join '', <FH>;
>    } else {
>      my $cmd = $self->_quote_args(@cmd);
>
>
> Committing.
>
>  -Ken
>
> On Apr 9, 2006, at 12:53 AM, Randy W. Sims wrote:
>
>> randys@new-pieria:~/Module-Build$ ~/perl5.005/bin/perl5.00504  
>> Build.PL
>>
>> Too many arguments for open at lib/Module/Build/Base.pm line 355,  
>> near "@cmd or"BEGIN not safe after errors--compilation aborted at  
>> lib/Module/Build/Base.pm line 574.
>> BEGIN failed--compilation aborted at lib/Module/Build.pm line 14.
>> BEGIN failed--compilation aborted at Build.PL line 10.
>>
>>
>> -------------------------------------------------------
>> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
>> language
>> that extends applications into web and mobile media. Attend the  
>> live webcast
>> and join the prime developer group breaking into this new coding  
>> territory!
>> http://sel.as-us.falkag.net/sel? 
>> cmd=lnk&kid=110944&bid=241720&dat=121642
>> _______________________________________________
>> Module-build-general mailing list
>> Mod...@li...
>> https://lists.sourceforge.net/lists/listinfo/module-build-general
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting  
> language
> that extends applications into web and mobile media. Attend the  
> live webcast
> and join the prime developer group breaking into this new coding  
> territory!
> http://sel.as-us.falkag.net/sel? 
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general

Re: [Module::Build] Fwd: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[Ken W. <ke...@ma...>]

On Apr 9, 2006, at 4:16 PM, demerphq wrote:

> Notable changes are better Win32 support for in-use files

Awesome, glad to hear this is released now.

  -Ken

Re: [Module::Build] Preserving files' executable bits, once more

[Ken W. <ke...@ma...>]

On Apr 8, 2006, at 11:17 PM, Randy W. Sims wrote:
>
> Borrowing code from ExtUtils::Install::install() and ::pm_to_blib 
> (), the copy_if_modified() method now preserves file mode and  
> timestamps.

Sounds good to preserve mode, but I'm not sure we want to preserve  
timestamps.  Seems like the timestamp can be a useful indicator of  
when a file got updated.

  -Ken

Re: [Module::Build] Wrapup: Are there any open issues I haven't recently addressed?

[Yitzchak Scott-T. <sth...@ef...>]

On Sun, Apr 09, 2006 at 12:20:27PM -0400, Randy W. Sims wrote:
> 
> After losing my notes, I'm at a little bit of a disadvantage.
> 
> If there are any open issues that I haven't responded to in the last few 
> days or that are not already logged in RT, please let me know.

Don't know if this is the kind of thing you mean, but you didn't weigh
in on this:

On Mon, Jan 23, 2006 at 07:49:44PM -0600, Ken Williams wrote:
>
> On Jan 23, 2006, at 6:43 AM, Yitzchak Scott-Thoennes wrote:
>
> >I raised this question once before, in particular about Module::Build
> >itself.  If a module only has auto_features, not features or
> >config_data, would it cause any harm to have the ConfigData module
> >built at the time of distmeta and included in the distribution?
>
> Hmm, I never thought about it in exactly those terms before.  I can't
> think of any problem myself.  I suppose you'd get different results
> just because the version of M::B that builds the ConfigData module is
> going to be the one on the author's machine, not the user's, but that's
> probably not a big deal (or perhaps it's even mildly desirable).
>
>  -Ken

[Module::Build] Re: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[Rafael Garcia-S. <rga...@gm...>]

On 09/04/06, demerphq <dem...@gm...> wrote:
> In ex-ExtUtils-Install-1.3702 I made the mistake of letting
> MANIFEST.SKIP be used when no INSTALL.SKIP was present but this
> prevented some packages from installing as their MANIFEST.SKIP
> contained the patter /blib/ which as it is in most install source
> paths meant that nothing would get installed at all. 1.38 fixes this
> problem by using INSTALL.SKIP only, but allows
> EU_INSTALL_SITE_SKIPFILE to be set to a site specific file for generic
> use.

OK, that was the explanation I was looking for :) Thanks.

[Module::Build] Re: CPAN Upload: Y/YV/YVES/ExtUtils-Install-1.38.tar.gz

[demerphq <dem...@gm...>]

On 4/9/06, Rafael Garcia-Suarez <rga...@gm...> wrote:
> On 09/04/06, demerphq <dem...@gm...> wrote:
> > Notable changes are better Win32 support for in-use files, and support
> > for an INSTALL.SKIP file to prevent stuff being installed that
> > shouldnt be. This should be particularly useful for folks that use SVN
> > and would like to be able to do an install directly from their working
> > directory without install svn directories into their perl module tree.
>
> How does the purpose of this file differ from the one of MANIFEST.SKIP ?

ExtUtils::Install::install() pays no attention to MANIFEST.SKIP and never h=
as.

MANIFEST.SKIP is to prevent stuff from getting added to MANIFEST when
you do something like

  make manifest

which is a distinct process from installation.Installation is
performed by doing stuff like moving all files under one path to
another path, INSTALL.SKIP allows you to prevent specific filetypes or
files from being included in such a process.

Examples uses for this could be on Win32 to filter out the
installation of XS/C compilation byproduct like *.pdb. I personally
use it for stuff like preventing .bak from getting installed and for
keeping .svn out of my site/lib tree.

In ex-ExtUtils-Install-1.3702 I made the mistake of letting
MANIFEST.SKIP be used when no INSTALL.SKIP was present but this
prevented some packages from installing as their MANIFEST.SKIP
contained the patter /blib/ which as it is in most install source
paths meant that nothing would get installed at all. 1.38 fixes this
problem by using INSTALL.SKIP only, but allows
EU_INSTALL_SITE_SKIPFILE to be set to a site specific file for generic
use.

Cheers,
Yves


--
perl -Mre=3Ddebug -e "/just|another|perl|hacker/"