Re: Proposal for MakeMaker: $ENV{PERL_MM_DEFAULT_DB}
Michael G Schwern [EMAIL PROTECTED] wrote:
On Thu, Oct 16, 2003 at 06:08:34PM +, Slaven Rezic wrote:
Here's a proposal for better default value handling in Makefile.PL's.
It's basically an extension to the existing prompt() function. If
$ENV{PERL_MM_DEFAULT_DB} is defined, then it is used as a file
location for an AnyDBM_File. User input to prompt() will be stored
into this database and used next time as the default value. Furthermore,
if prompt() is called with a third parameter, then it is used for
parsing the command line for this argument. In this case, the user will
not be queried, but the specified value will go into the database
(this is debatable).
What does that do that:
cat response_file | perl Makefile.PL
doesn't? Or a little expect-type script?
Makefile.PL should read from STDIN just fine.
This is hard to do from CPAN.pm/CPANPLUS.pm.
Regards,
Slaven
--
Slaven Rezic - slaven at rezic dot de
Re: Proposal for MakeMaker: $ENV{PERL_MM_DEFAULT_DB}
Michael G Schwern [EMAIL PROTECTED] wrote:
On Fri, Oct 17, 2003 at 10:06:16AM +, Slaven Rezic wrote:
Michael G Schwern [EMAIL PROTECTED] wrote:
On Thu, Oct 16, 2003 at 06:08:34PM +, Slaven Rezic wrote:
Here's a proposal for better default value handling in Makefile.PL's.
It's basically an extension to the existing prompt() function. If
$ENV{PERL_MM_DEFAULT_DB} is defined, then it is used as a file
location for an AnyDBM_File. User input to prompt() will be stored
into this database and used next time as the default value. Furthermore,
if prompt() is called with a third parameter, then it is used for
parsing the command line for this argument. In this case, the user will
not be queried, but the specified value will go into the database
(this is debatable).
What does that do that:
cat response_file | perl Makefile.PL
doesn't? Or a little expect-type script?
Makefile.PL should read from STDIN just fine.
This is hard to do from CPAN.pm/CPANPLUS.pm.
How do you plan on assigning PERL_MM_DEFAULT_DB on a per module basis
from CPAN/CPANPLUS? Or will you build One Grand Default File and One
Grand Makefile.PL Parser?
PERL_MM_DEFAULT_DB is global for all modules. The key of the dbm file
could be $extension_name $prompt_text. An additional Makefile.PL
parser is not necessary, just the change to prompt() [and telling the
module authors to use prompt() everywhere interactive configuration
is necessary].
Regards,
Slaven
--
Slaven Rezic - slaven at rezic dot de
Re: [Fwd: Re: MARC: msg 'cvs commit: modperl .cvsignore']
On Tue, Oct 14, 2003 at 02:16:44PM -0700, Stas Bekman wrote:
Michael, any idea why the default behavior is to always overwrite META.yml?
As more projects will start maintaining it, they all will have to specify
NO_META. Shouldn't it be the opposite: overwrite only if explicitly told to?
Ideally it would read in the existing one, update any entries it can
reliably determine the value for, add anything that's missing and
write it out to a new file. If the new files doesn't match the old
then replace it (and die if it's readonly).
Tim.
Original Message
On Tue, 2003-10-14 at 14:03, Stas Bekman wrote:
Philippe M. Chiasson wrote:
[...]
Do docs say anything about it? If not a bugreport to the makemaker list?
It shouldn't overwrite an existing META.yml, that's for sure.
The docs seem to document it as a feature:
make distdir
Copies all the files that are in the MANIFEST file to a newly
cre-
ated directory with the name $(DISTNAME)-$(VERSION). If that
directory exists, it will be removed first.
Additionally, it will create a META.yml module meta-data file and
add this to your MANFIEST. You can shut this behavior off with
the
NO_META flag.
I do agree with you, though, that it shouldn't overwrite an existing
META.yml. Lemme go find out if I ahve the latest EU::MM
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
--
Philippe M. Chiasson /gozer\@(cpan|ectoplasm)\.org/ 88C3A5A5
(122FF51B/C634E37B)
http://gozer.ectoplasm.org/F9BF E0C2 480E 7680 1AE5 3631 CB32 A107 88C3
A5A5
Q: It is impossible to make anything foolproof because fools are so
ingenious.
perl
-e'$$=\${gozer};{$_=unpack(P7,pack(L,$$));/^JAm_pH\n$/print||$$++redo}'
--
__
Stas BekmanJAm_pH -- Just Another mod_perl Hacker
http://stason.org/ mod_perl Guide --- http://perl.apache.org
mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com
http://modperlbook.org http://apache.org http://ticketmaster.com
Re: [Fwd: Re: MARC: msg 'cvs commit: modperl .cvsignore']
On Tuesday, October 14, 2003, at 04:16 PM, Stas Bekman wrote: Michael, any idea why the default behavior is to always overwrite META.yml? As more projects will start maintaining it, they all will have to specify NO_META. Shouldn't it be the opposite: overwrite only if explicitly told to? I think most projects would want the META.yml overwritten by default. I certainly do in my projects, because it will update all the information for me. I don't think many people are maintaining the metadata by hand like you are. -Ken
Re: Proposal for MakeMaker: $ENV{PERL_MM_DEFAULT_DB}
On Fri, Oct 17, 2003 at 10:35:36AM +, Slaven Rezic wrote:
How do you plan on assigning PERL_MM_DEFAULT_DB on a per module basis
from CPAN/CPANPLUS? Or will you build One Grand Default File and One
Grand Makefile.PL Parser?
PERL_MM_DEFAULT_DB is global for all modules. The key of the dbm file
could be $extension_name $prompt_text. An additional Makefile.PL
parser is not necessary, just the change to prompt() [and telling the
module authors to use prompt() everywhere interactive configuration
is necessary].
I simply don't see this as scaling. The text of the prompts is going to
change in small ways all the time, so you can't rely on simply string
equality. Regexes might be able to get away with it, but than requires
an MLDBM approach to the DBM file since we now have to do something like
this:
my $defaults = $Default_DB{$module_name};
my $value;
foreach my $regex (keys $defaults) {
if( $prompt =~ /$regex/ ) {
$value = $defaults-{$regex};
last;
}
}
And how do you edit that DBM file? Do we need to ship a tool for that
as well or does every user write their own program for that?
And then what about Module::Build-based modules? Do they need to
duplicate that?
No, this is definately a major new feature that I don't want to get into.
Also, this strikes me as something better handled inside the CPAN shell.
--
Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/
I need a SHOWER a BURGER and some ROBOTS, STAT!
-- http://www.angryflower.com/allrigh.gif
Re: Proposal for MakeMaker: $ENV{PERL_MM_DEFAULT_DB}
Michael G Schwern [EMAIL PROTECTED] wrote:
On Fri, Oct 17, 2003 at 10:35:36AM +, Slaven Rezic wrote:
How do you plan on assigning PERL_MM_DEFAULT_DB on a per module basis
from CPAN/CPANPLUS? Or will you build One Grand Default File and One
Grand Makefile.PL Parser?
PERL_MM_DEFAULT_DB is global for all modules. The key of the dbm file
could be $extension_name $prompt_text. An additional Makefile.PL
parser is not necessary, just the change to prompt() [and telling the
module authors to use prompt() everywhere interactive configuration
is necessary].
I simply don't see this as scaling. The text of the prompts is going to
change in small ways all the time, so you can't rely on simply string
equality. Regexes might be able to get away with it, but than requires
an MLDBM approach to the DBM file since we now have to do something like
this:
my $defaults = $Default_DB{$module_name};
my $value;
foreach my $regex (keys $defaults) {
if( $prompt =~ /$regex/ ) {
$value = $defaults-{$regex};
last;
}
}
I thought of a solution that is non-intrusive as possible. The perfect
solution would be to change prompt() to accept ($text, $default, $identifier)
and use the $identifier as databsae key. However this requires changing
all the prompts() calls in the existing Makefile.PLs.
And how do you edit that DBM file? Do we need to ship a tool for that
as well or does every user write their own program for that?
Something like
perl -MTk -MTk::ObjEditor -MAnyDBM_File -e 'tie %db, AnyDBM_File,
/tmp/perl-defaults.db, O_RDONLY, 0666; tkinit-ObjEditor(caller = \%db)-pack;
MainLoop'
could work :-) But it's probably better to use a YAML file instead.
And then what about Module::Build-based modules? Do they need to
duplicate that?
Yes.
No, this is definately a major new feature that I don't want to get into.
Also, this strikes me as something better handled inside the CPAN shell.
How? CPAN.pm doesn't know anything about the user's interaction with
Makefile.PL. I also think that the feature is also useable for
non-CPAN.pm operation. prompt() lacks a history function and it's
often cumbersome to enter the same values again and again if
somewhere happens to be a mistake.
Regards,
Slaven
--
Slaven Rezic - slaven at rezic dot de
Re: [Fwd: Re: MARC: msg 'cvs commit: modperl .cvsignore']
On Fri, Oct 17, 2003 at 10:36:25AM -0700, Stas Bekman wrote: Michael, any idea why the default behavior is to always overwrite META.yml? As more projects will start maintaining it, they all will have to specify NO_META. Shouldn't it be the opposite: overwrite only if explicitly told to? Hmm, this is the first I've noticed of this conversation so I don't know the context. Yes, it should be overwritten by default because most projects shouldn't even know its there. Part of the reason for slipping META.yml generation quietly into MakeMaker was to rapidly populate CPAN with meta information without making all the CPAN authors aware of it and having them all add a new flag to their module. Now it just happens the next time they upload a new version of their module with a recent MakeMaker. NO_META is definately in the minority. I wish I still had my CPAN Makefile.PL scanning script to throw up some statistics. I think most projects would want the META.yml overwritten by default. I certainly do in my projects, because it will update all the information for me. I don't think many people are maintaining the metadata by hand like you are. I agree with Ken, I don't think many people are even aware its exists. If that's the case, then OK we can use NO_META. But I think just like Makefile is moved to Makefile.old, the old META.yml should at least be moved to META.old when overwritten and may be a warning issued? Having META.old might be useful, like make manifest. But a warning would just be an annoyance as META.yml is overwritten as part of normal operation. It can't tell the difference between a MakeMaker generated META.yml and a user generated one. More to the point, what's the real issue here? Did you edit META.yml by hand and forget to set NO_META and find your changes lost in the next version? In this case maybe a little this file was created by MakeMaker: do not edit in the META.yml might make sense. Also, what is/isn't MakeMaker doing that you need to maintain META.yml yourself? -- Michael G Schwern[EMAIL PROTECTED] http://www.pobox.com/~schwern/ Never underestimate the bandwidth of a mag tape on a bicycle. -- Carl Friedberg in [EMAIL PROTECTED]
