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

[Module::Build] ./Build dist - files not added which aren't enlisted in MANIFEST?

[Steven S. <sch...@cp...>]

As I was in the process of adding a freshly created testfile to 
the subdirectory t/ of a distribution I got biten when I ran 
the dist action because it was my natural assumption that the new 
file would be implicitly integrated - but it wasn't.

So I had to rerun the manifest action on it to have it included.

Is this intentional behaviour? If not, shouldn't we emit a warning
for all files which aren't currently included and are not subject 
to exclusion by MANIFEST.SKIP when running the dist action?

-- 
In ancient times cats were worshipped as gods;
they have not forgotten this. 
    -- Terry Pratchett

Re: [Module::Build] Invoking Build.PL/Makefile.PL from automake?

[Tyler M. <ty...@yi...>]

Randy W. Sims <ml...@th...> wrote:
> I don't know enough about the autotools to answer, but I'd be very 
> curious to learn what you come up with.

	So far, nothing too hot:

--snip--
PERL_MODULE = Net-BitTorrent-LibBTT/blib/arch/auto/Net/BitTorrent/LibBTT/LibBTT.so

Net-BitTorrent-LibBTT/Makefile: Net-BitTorrent-LibBTT/Makefile.PL
	cd Net-BitTorrent-LibBTT && \
        APR_CONFIG=@APR_CONFIG@ $(PERL) Makefile.PL \
        CCFLAGS="-I../.. $(CPPFLAGS) $(CFLAGS)" LDDLFLAGS=$(LDDLFLAGS)

$(PERL_MODULE): Net-BitTorrent-LibBTT/Makefile
	$(MAKE) -C Net-BitTorrent-LibBTT


if BUILD_PERL

install-exec-local:: $(PERL_MODULE)
	$(MAKE) -C Net-BitTorrent-LibBTT install
        
clean-local::
	@if test -e Net-BitTorrent-LibBTT/Makefile; then $(MAKE) -C
Net-BitTorrent-LibBTT distclean; fi

all-local:: $(PERL_MODULE)

endif
--snip--


	Ideally, I want to generalize this a bit more. The main problem is
dertermining a good "make" target to signify that a module has been
compiled. There's pm_to_blib, but that's not always accurate. Or maybe I
should just dumbly "make" in the perl directory every single time an
appropriate target is invoked from outside? Either way, make/automake need a
target they can point at and say "ah, that means the perl module"...

		- Tyler

Re: [Module::Build] svk pulling

[David G. <da...@hy...>]

Ken Williams wrote:

>> svk mirror --detach /module-build/mirror
>> svk rm /module-build/mirror
>>
>> The latter might cause problems since you appeared to have merged from 
>> it.
> 
> Not that I'm aware of, but it's possible.
> 
> After I perform these steps, I can just delete all of 
> ~/.subversion/module-build , right?  Or should I be afraid of that?

I'm not sure what that directory holds.

> So in this case I probably just want "svk update"?  If I want to get 
> myself up to date in a mirrored copy I do "svk update", and if I'm in a 
> local copy I do "svk pull"?

That's right, though you want "svk update -s" to sync the mirror first 
before the update.

David

Re: [Module::Build] svk pulling

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

On Apr 20, 2006, at 1:03 PM, David Golden wrote:

> Ken Williams wrote:
>> Hey,
>> I'm having some kind of problem with SVK I'm not sure how to  
>> handle.  I wanted to go into the release-0_26_branch and maybe  
>> make a bug fix, so I went to my working directory:
>> % svk info
>> Checkout Path: /Users/ken/src/Module-Build-svk-0.26
>> Depot Path: //mirror/module-build/branches/release-0_26_branch
>> Revision: 1874
>> Last Changed Rev.: 1828
>> Mirrored From: https://svn.perl.org/modules/Module-Build, Rev. 5932
>> Copied From: /mirror/module-build/trunk, Rev. 1147
>> Merged From: /mirror/module-build/trunk, Rev. 1147
>> % svk mirror --list
>> Path                    Source
>> ============================================================
>> //mirror/module-build   https://svn.perl.org/modules/Module-Build
>> /module-build/mirror    http://svn.perl.org/modules/Module-Build
>> (Ignore that second mirror, I don't use it and I want it to go away.)
>
> svk mirror --detach /module-build/mirror
> svk rm /module-build/mirror
>
> The latter might cause problems since you appeared to have merged  
> from it.

Not that I'm aware of, but it's possible.

After I perform these steps, I can just delete all of ~/.subversion/ 
module-build , right?  Or should I be afraid of that?


>> When I perform "svk pull" in /Users/ken/src/Module-Build- 
>> svk-0.26 , I get notified of a lot of conflicts.  I figure,  
>> whatever, I haven't ever made changes in this directory, so I  
>> "accept theirs" for all the conflicts, thinking that will just get  
>> me a fresh version of stuff.  But then if I do "svk pull" again in  
>> the same directory, I get the same set of conflicts.
>
> I believe "svk pull" is shorthand for "svk update -sm".  It's  
> really designed for when you're working on something checked out  
> from a local copy of a mirrored directory -- you want to sync the  
> mirror, then smerge the changes from the mirror to the local copy,  
> then update your checkout with the local copy.

So in this case I probably just want "svk update"?  If I want to get  
myself up to date in a mirrored copy I do "svk update", and if I'm in  
a local copy I do "svk pull"?


>
> However, you're operating directly against the mirrored directory,  
> so when you pull, I think the smerge is going back to the trunk  
> (i.e. where the mirror directory was last merged from) and trying  
> to pull in changes from that.  Since you haven't checked in the  
> changes (and you probably shouldn't!) I suspect that each pull is  
> finding the differences from the trunk and the 0.26 branch.
>
> When you're working directly from a mirrored directory, I think you  
> really just want to do "svk update -s" which syncs the mirror and  
> then updates your working files from the mirror.
>
> Frankly, I think much of the benefit of svk comes from using local  
> copies.  You can check in your own incremental work in the local  
> copy without affecting what anyone else upstream sees.  Once you're  
> happy with your changes, you can then merge it all back upstream,  
> either individually ("svk push") or all together ("svk push -l").

That makes sense.  I think I don't need this very often on the M::B  
project since a lot of my changes are either pretty small or I try to  
check them in incrementally with no breakage, but sometimes it could  
be valuable.

  -Ken

Re: [Module::Build] svk pulling

[David G. <da...@hy...>]

Ken Williams wrote:
> Hey,
> 
> I'm having some kind of problem with SVK I'm not sure how to handle.  I 
> wanted to go into the release-0_26_branch and maybe make a bug fix, so I 
> went to my working directory:
> 
> % svk info
> Checkout Path: /Users/ken/src/Module-Build-svk-0.26
> Depot Path: //mirror/module-build/branches/release-0_26_branch
> Revision: 1874
> Last Changed Rev.: 1828
> Mirrored From: https://svn.perl.org/modules/Module-Build, Rev. 5932
> Copied From: /mirror/module-build/trunk, Rev. 1147
> Merged From: /mirror/module-build/trunk, Rev. 1147
> 
> % svk mirror --list
> Path                    Source
> ============================================================
> //mirror/module-build   https://svn.perl.org/modules/Module-Build
> /module-build/mirror    http://svn.perl.org/modules/Module-Build
> 
> (Ignore that second mirror, I don't use it and I want it to go away.)

svk mirror --detach /module-build/mirror
svk rm /module-build/mirror

The latter might cause problems since you appeared to have merged from it.

> When I perform "svk pull" in /Users/ken/src/Module-Build-svk-0.26 , I 
> get notified of a lot of conflicts.  I figure, whatever, I haven't ever 
> made changes in this directory, so I "accept theirs" for all the 
> conflicts, thinking that will just get me a fresh version of stuff.  But 
> then if I do "svk pull" again in the same directory, I get the same set 
> of conflicts.

I believe "svk pull" is shorthand for "svk update -sm".  It's really 
designed for when you're working on something checked out from a local 
copy of a mirrored directory -- you want to sync the mirror, then smerge 
the changes from the mirror to the local copy, then update your checkout 
with the local copy.

However, you're operating directly against the mirrored directory, so 
when you pull, I think the smerge is going back to the trunk (i.e. where 
the mirror directory was last merged from) and trying to pull in changes 
from that.  Since you haven't checked in the changes (and you probably 
shouldn't!) I suspect that each pull is finding the differences from the 
trunk and the 0.26 branch.

When you're working directly from a mirrored directory, I think you 
really just want to do "svk update -s" which syncs the mirror and then 
updates your working files from the mirror.

Frankly, I think much of the benefit of svk comes from using local 
copies.  You can check in your own incremental work in the local copy 
without affecting what anyone else upstream sees.  Once you're happy 
with your changes, you can then merge it all back upstream, either 
individually ("svk push") or all together ("svk push -l").

Here's how I'd work:

svk mi https://svn.perl.org/Module-Build/ //mirror/Module-Build

svk sync //mirror/Module-Build

svk cp -m "local copy" 
//mirror/Module-Build/branches/release-0_26_branch 
//local/Module-Build-0_26_branch

svk co //local/Module-Build-0_26_branch Module-Build-0.26

Hope that helps,

David Golden

[Module::Build] svk pulling

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

Hey,

I'm having some kind of problem with SVK I'm not sure how to handle.   
I wanted to go into the release-0_26_branch and maybe make a bug fix,  
so I went to my working directory:

% svk info
Checkout Path: /Users/ken/src/Module-Build-svk-0.26
Depot Path: //mirror/module-build/branches/release-0_26_branch
Revision: 1874
Last Changed Rev.: 1828
Mirrored From: https://svn.perl.org/modules/Module-Build, Rev. 5932
Copied From: /mirror/module-build/trunk, Rev. 1147
Merged From: /mirror/module-build/trunk, Rev. 1147

% svk mirror --list
Path                    Source
============================================================
//mirror/module-build   https://svn.perl.org/modules/Module-Build
/module-build/mirror    http://svn.perl.org/modules/Module-Build

(Ignore that second mirror, I don't use it and I want it to go away.)

When I perform "svk pull" in /Users/ken/src/Module-Build-svk-0.26 , I  
get notified of a lot of conflicts.  I figure, whatever, I haven't  
ever made changes in this directory, so I "accept theirs" for all the  
conflicts, thinking that will just get me a fresh version of stuff.   
But then if I do "svk pull" again in the same directory, I get the  
same set of conflicts.

Help?

  -Ken

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

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

On Apr 19, 2006, at 3:50 AM, Randy W. Sims wrote:
> I've gone ahead and comitted what I have as an initial  
> implementation to give something concrete to play with, and as a  
> base with which to experiment with the other remaining issues.

Thanks, Randy.  I'll play around with it some.  If you see me make  
some change you don't like, be sure to let me know.

  -Ken

Re: [Module::Build] META.yml and platform dependencies.

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

On Apr 19, 2006, at 1:46 AM, Andreas J. Koenig wrote:

> Index: lib/CPAN.pm
> ===================================================================
> --- lib/CPAN.pm (revision 717)
> +++ lib/CPAN.pm (working copy)
> @@ -5378,6 +5378,11 @@
>              $CPAN::Frontend->mywarn("Error while parsing META.yml:  
> $@");
>              return;
>          }
> +        if (not exists $self->{yaml_content}{dynamic_content}
> +            or $self->{yaml_content}{dynamic_content}
> +           ) {
> +            $self->{yaml_content} = undef;
> +        }
>      }

s/content/config/g;

Just a reminder, in case you missed it earlier in the discussion,  
that once the Build.PL script gets run, there's a file _build/prereqs  
that will dependably list the prereqs, including responses to any  
user questions, probing of the system, etc.

  -Ken

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

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

Ken Williams wrote:
> 
> On Apr 14, 2006, at 4:44 AM, Randy W. Sims wrote:
> 
>> +
>> +=item default   [required]
>> +
>> +This is the default value that will be used if the user presses
>> +E<lt>enterE<gt> or if running an unattended build.
>> +
>> +The value assigned to C<default> may be different from the options
>> +listed in the C<options> argument.
> 
> I think I'm about to blaspheme, but I think sometimes we shouldn't 
> require there to be a default.
> 
> /me ducks
> 
> Sometimes there's simply no way to build & test & install a module 
> without user intervention.  For example, Inline::Java asks you to tell 
> it where the J2SDK installation is, and there's no default.
> 
> If we changed the error message to something appropriate, I think we 
> could handle this case gracefully, both here and in y_n().  Something like:
> 
>   if ( $ENV{PERL_MM_USE_DEFAULT} && !$def ) {
>     die <<EOF;
> ERROR: PERL_MM_USE_DEFAULT is in effect, but there is no default value.  
> Aborting.
> EOF
>   }
> 
> It might be nice to note this fact in the META.yml file, using a flag 
> like 'interactive_install' or something, so that automated testers don't 
> even try to download & build the distro.
> 
> For a distro that really requires interaction like this, the author 
> could work around our proposed required 'default' by setting 'default' 
> to undef and then die()ing with their own error message if prompt() or 
> y_n() or ask() returned undef, but why not provide them with the 
> appropriate sugar?

Here's a rough rough patch to implement something along those lines, I 
think. Rough day, my brains not working well, and somehow this simple 
little input routine has become one of the largest routines in M::B, so 
I'd appreciate feedback. All names, behaviors, and every last byte 
subject to change.

Randy.

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

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

Ken Williams wrote:
> 
> On Apr 14, 2006, at 4:44 AM, Randy W. Sims wrote:
> 
>> +
>> +=item allow_nonoption_default
>> +
>> +Normally, the value of the C<default> arguement must exist in the
>> +C<options> array.  Setting this to true allows the C<default>  argument
>> +to be set to an arbitrary value.
> 
> 
> I do still wonder about the need for this parameter.  The author  could 
> just as easily put the value in the options array, and probably  with 
> less typing.
> 
> Not a big deal, though.
> 
> Let's at least update the verbiage to read something like this,  
> indicating that C<options> isn't required:
> 
> +=item allow_nonoption_default
> +
> +Normally, if an C<options> array is present, then the value of the  
> C<default>
> +argument must exist in C<options>.  Setting  C<allow_nonoption_default> 
> to true
> +allows the C<default> argument to be set to an arbitrary value.

I've done this as well as implemented the 'on_validate' callback. The 
callback return value behavior is a little weird, but it's the least 
weird I could think of at the moment. Overall, I think it will work well.

I've gone ahead and comitted what I have as an initial implementation to 
give something concrete to play with, and as a base with which to 
experiment with the other remaining issues.

Randy.

Re: [Module::Build] META.yml and platform dependencies.

[<and...@fr...>]

>>>>> On Wed, 19 Apr 2006 07:25:14 +0200, demerphq <dem...@gm...> said:

  > I said this before, but im not sure you saw it, I was thinking that
  > dynamic_config=>1 be done by re-generating the META.yml on the local
  > machine.

I think, for CPAN.pm it's enough to just do this (untested):


Index: lib/CPAN.pm
===================================================================
--- lib/CPAN.pm (revision 717)
+++ lib/CPAN.pm (working copy)
@@ -5378,6 +5378,11 @@
             $CPAN::Frontend->mywarn("Error while parsing META.yml: $@");
             return;
         }
+        if (not exists $self->{yaml_content}{dynamic_content}
+            or $self->{yaml_content}{dynamic_content}
+           ) {
+            $self->{yaml_content} = undef;
+        }
     }
     $self->debug("yaml_content[$self->{yaml_content}]") if $CPAN::DEBUG;
     return $self->{yaml_content};


I'd expect that this should work because CPAN.pm should then follow
the logic without a META.yml or without YAML.pm installed and this
path usually was working well.

-- 
andreas

Re: [Module::Build] META.yml and platform dependencies.

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

On 4/19/06, Andreas J. Koenig <and...@fr...> wr=
ote:
> >>>>> On Wed, 12 Apr 2006 22:06:43 -0500, Ken Williams <ke...@ma...=
> said:
>
>   > Hi Yves,
>   > This is a known shortcoming of CPAN's approach to dependency
>   > detection.  There's no solution inside the META.yml itself, though in
>   > some distant future version we'd like to expand the little language
>   > that describes dependencies so it would indeed be capable of
>   > expressing platform-specific dependencies.
>
>   > In the meantime, I'm not sure what to suggest - if you omit the
>   > META.yml I assume CPAN would try another method, but I'm not sure.
>   > It's also possible that if you put dynamic_config =3D> 1 in the
>   > META.yml it could try another method, but I'm certainly not sure
>   > about that either. :-/
>
> I completely lost track of dynamic_config =3D> 1 at some point in time.
>
> =3D=3D> TODO

I said this before, but im not sure you saw it, I was thinking that
dynamic_config=3D>1 be done by re-generating the META.yml on the local
machine.

Cheers.
yves


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

Re: [Module::Build] META.yml and platform dependencies.

[Tyler M. <ty...@yi...>]

Andreas J. Koenig <and...@fr...> wrote:
>   > In the meantime, I'm not sure what to suggest - if you omit the
>   > META.yml I assume CPAN would try another method, but I'm not sure.
>   > It's also possible that if you put dynamic_config => 1 in the
>   > META.yml it could try another method, but I'm certainly not sure
>   > about that either. :-/
> I completely lost track of dynamic_config => 1 at some point in time.
> 
> ==> TODO

	I'd really like to see the META.yml spec officially support
optional_features as well. Then CPAN could be intelligent about those as
well. :-)

		- Tyler

Re: [Module::Build] META.yml and platform dependencies.

[<and...@fr...>]

>>>>> On Wed, 12 Apr 2006 22:06:43 -0500, Ken Williams <ke...@ma...> said:

  > Hi Yves,
  > This is a known shortcoming of CPAN's approach to dependency
  > detection.  There's no solution inside the META.yml itself, though in
  > some distant future version we'd like to expand the little language
  > that describes dependencies so it would indeed be capable of
  > expressing platform-specific dependencies.

  > In the meantime, I'm not sure what to suggest - if you omit the
  > META.yml I assume CPAN would try another method, but I'm not sure.
  > It's also possible that if you put dynamic_config => 1 in the
  > META.yml it could try another method, but I'm certainly not sure
  > about that either. :-/

I completely lost track of dynamic_config => 1 at some point in time.

==> TODO


-- 
andreas

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

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

On Apr 18, 2006, at 3:33 PM, John Peacock wrote:

> If M::B can know whether it is executing in mode #3, then the code  
> can differentiate between #2 and #3 already.  What is the use case  
> for a default value being something other than one of the prompted  
> values if not to determine whether the script is unmanned or the  
> user wants the code to make it's best guess (which should be the  
> same thing)?

One use case is when there's really no finite set of permissible  
values.  For example:

  prompt("What username should I use?", $ENV{USER});
  prompt("Generate how many fropps per second?", 80);
  prompt("Where is libfoo.a?", '/usr/lib');

Perhaps all three of those would benefit from a validation callback,  
though.


> That's the leap I'm not making.  If the author set a default value  
> that represents a "best guess" option that is different than one of  
> the manually typed options, why does there need to be a flag that  
> indicates that this is a valid value too.  A simple comparison  
> between the members of @options and $default already indicates that  
> something else is going on.

On the one hand, the author might typo the default and not realize  
it, and the explicit flag helps protect them against that.  On the  
other hand, they could accidentally typo the name of the flag too,  
but at least theoretically we could detect that.

  -Ken

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

[John P. <jpe...@ro...>]

Randy W. Sims wrote:
> (b) is not possible. If the user presses <enter> or <ctrl-d> without 
> typing anything, then the default will be used. So it's not an indicator 
> of an unattended build.

I thought that M::B already knew whether or not the Build.PL was running 
unattended or not.  AFAIUI, there are three modes:

1) the user types something - it has to match one of the entries in 
@options (and ask() helpfully prompts with the list of allowed values);

2) the user types nothing (<enter> or <ctrl-d>) - the value of default 
(or "" if none is set) is returned;

3) the script is running unattended - same effect as #2.

If M::B can know whether it is executing in mode #3, then the code can 
differentiate between #2 and #3 already.  What is the use case for a 
default value being something other than one of the prompted values if 
not to determine whether the script is unmanned or the user wants the 
code to make it's best guess (which should be the same thing)?

> IIUC, Ken's original point was that the 'default' argument could be 
> mistyped. Requiring the argument to 'default' to also appear in the 
> 'options' array is a safeguard and requires the author to verify or 
> explicitly allow the differing value. I strongly agree with this; I like 
> "safe" APIs.

Having been the unwitting victim of Cut/Paste error before, I don't give 
much weight to "type the same [possibly long] string here, too" types of 
constraints.

> The union of 'default' and 'options' does constitute the exclusive list 
> of permissible values. It's just that 'default' must be explicitly 
> declared to be different if it is not a member of 'options'.

That's the leap I'm not making.  If the author set a default value that 
represents a "best guess" option that is different than one of the 
manually typed options, why does there need to be a flag that indicates 
that this is a valid value too.  A simple comparison between the members 
of @options and $default already indicates that something else is going on.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD  20706
301-459-3366 x.5010
fax 301-429-5748

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

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

John Peacock wrote:
> Ken Williams wrote:
> 
>>I do still wonder about the need for this parameter.  The author  could
>>just as easily put the value in the options array, and probably  with
>>less typing.
> 
> 
> I also think this is needless frippery, but for the opposite reason.  How's this
> for an alternative definition:
> 
> The C<options> array is the list of displayed/prompted options to C<ask()> which
> a user can choose from; C<ask()> will not return until one of these values has
> been chosen.  The C<default> can either be one of the members of C<options> or
> some value to indicate that no answer could be obtained (such as would be the
> case if the Build.PL script had no controlling terminal).  As such, the union of
> the C<default> value with the C<options> array is the list of B<permissible>
> values, whereas the C<options> array is the list of values which satify an
> interactive C<ask()>.
> 
> This gets us both:
> 
> a) the total list of acceptable values, and
> b) a way to know for certain that the Build.PL script is running unmanned.

(b) is not possible. If the user presses <enter> or <ctrl-d> without 
typing anything, then the default will be used. So it's not an indicator 
of an unattended build.

> I don't see any reason to special case the $default <not-in> @options for a flag
> when we can infer it directly.

IIUC, Ken's original point was that the 'default' argument could be 
mistyped. Requiring the argument to 'default' to also appear in the 
'options' array is a safeguard and requires the author to verify or 
explicitly allow the differing value. I strongly agree with this; I like 
"safe" APIs.

The union of 'default' and 'options' does constitute the exclusive list 
of permissible values. It's just that 'default' must be explicitly 
declared to be different if it is not a member of 'options'.

Randy.

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

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

Ken Williams wrote:
> 
> On Apr 14, 2006, at 4:44 AM, Randy W. Sims wrote:
> 
>> +
>> +=item allow_nonoption_default
>> +
>> +Normally, the value of the C<default> arguement must exist in the
>> +C<options> array.  Setting this to true allows the C<default>  argument
>> +to be set to an arbitrary value.
> 
> 
> I do still wonder about the need for this parameter.  The author  could 
> just as easily put the value in the options array, and probably  with 
> less typing.

I was theorizing that sometimes the default would be some value that the 
author would not necessarily want to show up in the list of options as 
displayed to the user:

$mb->ask(prompt  => 'Does Randy ever finish when he says he will?',
          options => [qw(yes no)],
          default => 'never',
          allow_nonoption_default => 1,
);

The options 'yes' and 'no' will appear to the user, while the default 
value will not appear in the list:

Does Randy ever finish when he says he will? (yes/no)

I *do* hate typing 'allow_nonoption_default' though, or any extra 
arguement. I think I liked the exclamation as the first character of the 
default string for convenience.

$mb->ask(prompt  => 'Does Randy ever finish when he says he will?',
          options => [qw(yes no)],
          default => '!never',
);

But it's more obscure, and removes the ability to set 'default' to undef().

> Not a big deal, though.
> 
> Let's at least update the verbiage to read something like this,  
> indicating that C<options> isn't required:
> 
> +=item allow_nonoption_default
> +
> +Normally, if an C<options> array is present, then the value of the  
> C<default>
> +argument must exist in C<options>.  Setting  C<allow_nonoption_default> 
> to true
> +allows the C<default> argument to be set to an arbitrary value.

Current implementation is that 'default' is required to be in 'options' 
unless 'allow_nonoption_default' is set, regardless of whether the 
'options' argument is provided or not. I guess it would make sense to 
omit this requirement if no 'options' are defined.

>> +
>> +=item default   [required]
>> +
>> +This is the default value that will be used if the user presses
>> +E<lt>enterE<gt> or if running an unattended build.
>> +
>> +The value assigned to C<default> may be different from the options
>> +listed in the C<options> argument.
> 
> 
> I think I'm about to blaspheme, but I think sometimes we shouldn't  
> require there to be a default.
> 
> /me ducks

and quacks ;)

That was my entire motivation for this addition, but you're probably 
right. I had been thinking something similar, but I wasn't sure whether 
it should be a case-by-case arguement to ask(), a constructor arguement, 
or a simple global accessor.

> Sometimes there's simply no way to build & test & install a module  
> without user intervention.  For example, Inline::Java asks you to  tell 
> it where the J2SDK installation is, and there's no default.
> 
> If we changed the error message to something appropriate, I think we  
> could handle this case gracefully, both here and in y_n().  Something  
> like:
> 
>   if ( $ENV{PERL_MM_USE_DEFAULT} && !$def ) {
>     die <<EOF;
> ERROR: PERL_MM_USE_DEFAULT is in effect, but there is no default  
> value.  Aborting.
> EOF
>   }

That's exactly what we currently do in y_n(). While prompt() always 
defaults to an empty string if $def is not provided. I'm thinking ask() 
should require a default unless explicitly told otherwise, and I really 
do think it should be explicit, otherwise there is not much benefit to 
adding ask() over the existing prompt() and y_n().

I'm also not sure that we should rely on PERL_MM_USE_DEFAULT for the 
ask() method. As above, I think there should be an explicit statement by 
the author that says this build can't be run unattended.

We also need to keep in mind usages like:

open(STDIN, 'answers') or die "$!";
my $mb = Module::Build->new_from_context;


> It might be nice to note this fact in the META.yml file, using a flag  
> like 'interactive_install' or something, so that automated testers  
> don't even try to download & build the distro.

I think that would be very desirable and it would eliminate some 
complaints from testers. Although, I favor 'build' over install:

interactive_build
unattended_build

> For a distro that really requires interaction like this, the author  
> could work around our proposed required 'default' by setting  'default' 
> to undef and then die()ing with their own error message if  prompt() or 
> y_n() or ask() returned undef, but why not provide them  with the 
> appropriate sugar?

Agreed.

>> +A reference to an array containing a list of valid options.  If  options
>> +are provided, C<ask()> will not return until a valid option is
>> +entered, or the C<default> is selected by pressing E<lt>enterE<gt>
>> +without entering a value.  Option names are case-insensitive, but the
>> +option returned will be normalized to the form used in the  argument to
>> +C<options>.  It is not necessary for the user to enter the entire
>> +option name; C<ask()> will accept any unambiguous sequence of
>> +characters that will match only one option.  Eg. If the options are
>> +C<qw(yes no)> it will accept any of 'y', 'ye', or 'yes' to mean
>> +yes.  The complete option name will be returned.
> 
> 
> Maybe we should make this conditional on an option called  
> 'allow_abbrev', default true, or something?

Yeah, yeah, add more work. =)

Randy.

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

[John P. <jpe...@ro...>]

Ken Williams wrote:
> I do still wonder about the need for this parameter.  The author  could
> just as easily put the value in the options array, and probably  with
> less typing.

I also think this is needless frippery, but for the opposite reason.  How's this
for an alternative definition:

The C<options> array is the list of displayed/prompted options to C<ask()> which
a user can choose from; C<ask()> will not return until one of these values has
been chosen.  The C<default> can either be one of the members of C<options> or
some value to indicate that no answer could be obtained (such as would be the
case if the Build.PL script had no controlling terminal).  As such, the union of
the C<default> value with the C<options> array is the list of B<permissible>
values, whereas the C<options> array is the list of values which satify an
interactive C<ask()>.

This gets us both:

a) the total list of acceptable values, and
b) a way to know for certain that the Build.PL script is running unmanned.

I don't see any reason to special case the $default <not-in> @options for a flag
when we can infer it directly.

John

-- 
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4720 Boston Way
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747

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

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

On Apr 14, 2006, at 4:44 AM, Randy W. Sims wrote:

> +
> +=item allow_nonoption_default
> +
> +Normally, the value of the C<default> arguement must exist in the
> +C<options> array.  Setting this to true allows the C<default>  
> argument
> +to be set to an arbitrary value.

I do still wonder about the need for this parameter.  The author  
could just as easily put the value in the options array, and probably  
with less typing.

Not a big deal, though.

Let's at least update the verbiage to read something like this,  
indicating that C<options> isn't required:

+=item allow_nonoption_default
+
+Normally, if an C<options> array is present, then the value of the  
C<default>
+argument must exist in C<options>.  Setting  
C<allow_nonoption_default> to true
+allows the C<default> argument to be set to an arbitrary value.



> +
> +=item default   [required]
> +
> +This is the default value that will be used if the user presses
> +E<lt>enterE<gt> or if running an unattended build.
> +
> +The value assigned to C<default> may be different from the options
> +listed in the C<options> argument.

I think I'm about to blaspheme, but I think sometimes we shouldn't  
require there to be a default.

/me ducks

Sometimes there's simply no way to build & test & install a module  
without user intervention.  For example, Inline::Java asks you to  
tell it where the J2SDK installation is, and there's no default.

If we changed the error message to something appropriate, I think we  
could handle this case gracefully, both here and in y_n().  Something  
like:

   if ( $ENV{PERL_MM_USE_DEFAULT} && !$def ) {
     die <<EOF;
ERROR: PERL_MM_USE_DEFAULT is in effect, but there is no default  
value.  Aborting.
EOF
   }

It might be nice to note this fact in the META.yml file, using a flag  
like 'interactive_install' or something, so that automated testers  
don't even try to download & build the distro.

For a distro that really requires interaction like this, the author  
could work around our proposed required 'default' by setting  
'default' to undef and then die()ing with their own error message if  
prompt() or y_n() or ask() returned undef, but why not provide them  
with the appropriate sugar?


> +A reference to an array containing a list of valid options.  If  
> options
> +are provided, C<ask()> will not return until a valid option is
> +entered, or the C<default> is selected by pressing E<lt>enterE<gt>
> +without entering a value.  Option names are case-insensitive, but the
> +option returned will be normalized to the form used in the  
> argument to
> +C<options>.  It is not necessary for the user to enter the entire
> +option name; C<ask()> will accept any unambiguous sequence of
> +characters that will match only one option.  Eg. If the options are
> +C<qw(yes no)> it will accept any of 'y', 'ye', or 'yes' to mean
> +yes.  The complete option name will be returned.

Maybe we should make this conditional on an option called  
'allow_abbrev', default true, or something?

  -Ken

Re: [Module::Build] Module::Build doesnt use ExtUtils::Install::pm_to_blib() and then has problems when MakeMaker did....

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

On 4/15/06, Randy W. Sims <ml...@th...> wrote:
> demerphq wrote:
> This should have been fixed by a change I made earlier this week. You
> might try the version in repository at:
>
>    svn co http://svn.perl.org/modules/Module-Build/trunk/

Yep, that works better.

> > Although i will admit im curious why EU::I::pm_to_blib() wasnt used.

??

> > Is there something wrong with it? Oh, also note that the error message
> > is somehow missing the $!, it seems to have been lost, not sure why.
>
> Hmm, looking at File::Copy, I don't see where it's being lost...

Nor did I.

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

Re: [Module::Build] Module::Build doesnt use ExtUtils::Install::pm_to_blib() and then has problems when MakeMaker did....

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

demerphq wrote:
> Hi,
> 
> I just upgraded to the latest Module::Build dev release on CPAN: 0.27_09
> 
> I've noticed that for packages where you have both a Makefile.PL and a
> Build.PL you get problems if you dont do a 'clean' before switching
> from one to the other.
> 
>>From what i can tell this is actually because Module::Build doesnt use
> ExtUtils::Install::pm_to_blib() to do the move like MakeMaker does,
> but rather rolls its own and has missed out (or deliberately left out)
> the logic of making the files in blib read only, and the related task
> of unreadonly'ing the target file before doing a refresh copy.

This should have been fixed by a change I made earlier this week. You 
might try the version in repository at:

   svn co http://svn.perl.org/modules/Module-Build/trunk/

> Although i will admit im curious why EU::I::pm_to_blib() wasnt used.
> Is there something wrong with it? Oh, also note that the error message
> is somehow missing the $!, it seems to have been lost, not sure why.

Hmm, looking at File::Copy, I don't see where it's being lost...

Randy.

[Module::Build] Module::Build doesnt use ExtUtils::Install::pm_to_blib() and then has problems when MakeMaker did....

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

Hi,

I just upgraded to the latest Module::Build dev release on CPAN: 0.27_09

I've noticed that for packages where you have both a Makefile.PL and a
Build.PL you get problems if you dont do a 'clean' before switching
from one to the other.

From what i can tell this is actually because Module::Build doesnt use
ExtUtils::Install::pm_to_blib() to do the move like MakeMaker does,
but rather rolls its own and has missed out (or deliberately left out)
the logic of making the files in blib read only, and the related task
of unreadonly'ing the target file before doing a refresh copy.

Although i will admit im curious why EU::I::pm_to_blib() wasnt used.
Is there something wrong with it? Oh, also note that the error message
is somehow missing the $!, it seems to have been lost, not sure why.

Cheers,
yves

D:\dev\cpan\ExtUtils-Install\trunk>Build test
lib\ExtUtils\Install.pm -> blib\lib\ExtUtils\Install.pm
Can't copy('lib\ExtUtils\Install.pm', 'blib\lib\ExtUtils\Install.pm'):
 at D:/ASPerl/811/site/lib/Module/Build/Base.pm line 3761.

D:\dev\cpan\ExtUtils-Install\trunk>copy lib\ExtUtils\Install.pm
blib\lib\ExtUtils\Install.pm
Overwrite blib\lib\ExtUtils\Install.pm? (Yes/No/All): y
Access is denied.
        0 file(s) copied.

D:\dev\cpan\ExtUtils-Install\trunk>attrib blib\lib\ExtUtils\Install.pm
A    R     D:\dev\cpan\ExtUtils-Install\trunk\blib\lib\ExtUtils\Install.pm

D:\dev\cpan\ExtUtils-Install\trunk>nmake

Microsoft (R) Program Maintenance Utility Version 7.00.9955
Copyright (C) Microsoft Corporation.  All rights reserved.

Skip blib\lib\ExtUtils\Installed.pm (unchanged)
cp lib/ExtUtils/Install.pm blib\lib\ExtUtils\Install.pm
Skip blib\lib\ExtUtils\Packlist.pm (unchanged)

D:\dev\cpan\ExtUtils-Install\trunk>


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

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

[David G. <da...@hy...>]

Ron Savage wrote:
> I'd prefer them in alphabetical order, for obvious reasons.

I concur.  For a while now, I've even been doing this in my code.  All 
functions get organized alphabetically, though I do group them into 
public, private, capitalized, etc.  I never have to wonder something is.

Regards,
David Golden

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

[Ron S. <ro...@sa...>]

On Fri, 14 Apr 2006 09:05:57 -0700, David Wheeler wrote:

Hi David

> I'd make this last. I tend to list options in the order of
> importance. So for this method, I would list them in this order:

What /you/ think is important :-)!

I'd prefer them in alphabetical order, for obvious reasons.
-- 
Cheers
Ron Savage, ro...@sa... on 15/04/2006
http://savage.net.au/index.html
Let the record show: Microsoft is not an Australian company