module-build-general Mailing List for Module::Build (Page 6)
Status: Beta
Brought to you by:
kwilliams
You can subscribe to this list here.
2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
(24) |
Sep
(2) |
Oct
(18) |
Nov
(36) |
Dec
(17) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2003 |
Jan
(3) |
Feb
(96) |
Mar
(82) |
Apr
(63) |
May
(90) |
Jun
(52) |
Jul
(94) |
Aug
(89) |
Sep
(75) |
Oct
(118) |
Nov
(101) |
Dec
(111) |
2004 |
Jan
(159) |
Feb
(155) |
Mar
(65) |
Apr
(121) |
May
(62) |
Jun
(68) |
Jul
(54) |
Aug
(45) |
Sep
(78) |
Oct
(80) |
Nov
(271) |
Dec
(205) |
2005 |
Jan
(128) |
Feb
(96) |
Mar
(83) |
Apr
(113) |
May
(46) |
Jun
(120) |
Jul
(146) |
Aug
(47) |
Sep
(93) |
Oct
(118) |
Nov
(116) |
Dec
(60) |
2006 |
Jan
(130) |
Feb
(330) |
Mar
(228) |
Apr
(203) |
May
(97) |
Jun
(15) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ken W. <ke...@ma...> - 2006-04-28 17:09:03
|
Hi all, The uploaded file Module-Build-0.28.tar.gz has entered CPAN as file: $CPAN/authors/id/K/KW/KWILLIAMS/Module-Build-0.28.tar.gz size: 180076 bytes md5: 8b3d9cf3eadebdfbe5847d80ed3a2d0b Thanks to those of you who have been patiently (or even non- patiently) waiting for this release. We promise to never take this long between major releases again. =) The list of changes between 0.26xx and 0.28 is very very long. It's listed below, chunked by the beta release in which the features appeared. Going forward from 0.28, I'm sure there will be some 0.28xx releases as we get people's reported bugs smooshed. I don't plan on creating a list of target features for the next big release, though - I think that's what significantly slowed down the 0.28 release cycle. The future releases will happen as they happen, with individual features being part of whatever release they happen to get done for. Thanks, -Ken 0.28 Thu Apr 27 22:25:00 CDT 2006 - When y_n() or prompt() are called without a default value and the build seems to be unattended (e.g. in automatic CPAN testing), we now die() with an error message rather than silently returning undef for prompt(), or looping indefinitely for y_n(). - When searching for '.modulebuildrc', return the first HOME-like directory that actually contains the file instead of the first existing directory. Document the search locations and the order searched. [Spotted by David Golden] - Split the API documentation out of Module::Build::Authoring into its own document: Module::Build::API. - We should not emit a warning if a Module::Build subclass is required in a Makefile.PL that is not bundled in the current distribution; it may be installed on the user's system. [Spotted by Tyler MacDonald] - copy_if_modified() now preserves the executable bit of the source file. [Spotted by Julian Mehnle] - Fixed compatibility of our screen-scraping the Test::Harness output so we can recognize the most recent Test::Harness version. [Steve Hay] - Backing out a requirement added in 0.27_06 on the method y_n() to always include a default. This behavior would cause existing build scripts to start failing. We now fail with a missing default only when $ENV{PERL_MM_USE_DEFAULT} is set because there is no reasonable default. - Make install_types() method smarter with respect to custom install types. - Add documentation for the install_base_relpaths() and prefix_relpaths() methods. Improved their usage for a public API, and added tests. 0.27_10 Tue Mar 28 22:50:50 CST 2006 - Added the create_packlist property, default true, which controls whether packlist files will be written during installation. This was already part of Module::Build 0.2609, but for some reason we've forgotten it in the 0.27_xx series. [Spotted by Steve Kirkup] - Document the versions of Module::Build where each feature, action, constructor argument, and method was first publicly documented. - More fixes for find_perl_interpreter() to work with BSD flavored UNIX: Ensure we always return absolute paths; throw an exception upon failure to find correct interperter; document everything. - We now include our own YAML.pm work-alike that we can use when the real YAML isn't installed. We might soon even start using it when YAML is installed, because the YAML API and dependency chain have been changing in unfavorable ways lately. [Stephen Adkins] - Fixed some shell-argument-quoting issues on VMS. In the process, we have added some support for avoiding tripping over shell-argument-quoting issues on other platforms too. [Initial patch by Craig A. Berry] 0.27_09 Sat Mar 11 22:48:54 EST 2006 - Fixed find_perl_interpreter() so we can find the perl executable when running from uninstalled perl even when $^X contains a relative path. [Yitzchak Scott-Thoennes] - Fixed warning message where we were printing the wrong field names. [Chris Dolan] - Added a 'testpodcoverage' action that runs a POD coverage check for all modules in the distribution. [Yanick Champoux] - Added a Cookbook example of subclassing to modify an action. [Dylan Martin and David Golden] - When building HTML documentation, we were opening the POD file and not checking whether the open succeeded, which of course caused problems down the line if it failed. Now we do "or die(...)" like everywhere else. [Spotted by Joerg Braun] 0.27_08 Fri Mar 3 21:22:41 CST 2006 - Due to shell quoting issues and differences in syntax between various flavors of Windows, the code for the 'pl2bat' utility distributed with Perl has been incorporated into M::B::P::Windows. [Thanks to Dr Bean and Ron Savage for help testing and isolating the problem.] - Modify add_build_element() so that it only adds elements if they don't already exist. [David Wheeler] - Fixed a bug in the 'pass-through' Makefile.PL in which we would die if CPAN::Shell->install returned false, but apparently this return value is unreliable. Now we only die if the module is actually unavailable after installation. - Fixed testing problems on VMS related to non-case-preserving filesystems. We now bundle Tie::CPHash in the distribution (just for testing purposes, it doesn't get installed) to help with this. [Craig Berry and Yitzchak Scott-Thoennes] - We incorrectly documented the 'dynamic_config' flag in the META.yml file as having a default value of false, but according to the META.yml spec (which, for heaven's sake, we wrote) its default value is true. Fixed. [Spotted by Adam Kennedy] - The have_c_compiler() method was dying if the ExtUtils::CBuilder module wasn't around, which is obviously an unhelpful thing to do. Now it just returns false. [Spotted by John Peacock] - Fix detection of $VERSION expressions that are not assignments. [Spotted by Chris Dolan] - Obfuscate one of our constructs that uses a $VERSION variable, because it was getting picked up by ExtUtils::MakeMaker's version-finder. [Spotted by Randal Schwartz] - The config_data script for querying and/or setting a module's config data was forgetting to call write() after setting config values (though setting feature values was working fine). Fixed. [Brian Duggan] - On Windows, remove the pl2bat generated 'Build.bat' script without the annoying "The batch file cannot be found." error. [Solution provided by RazTK and foxidrive on newsgroup alt.msdos.batch] - Our version comparisons should now work correctly with modules that use version.pm to delcare their versions (e.g. "our $VERSION = version->new('1.0.0')"). [John Peacock and Ron Savage] - We now create a Build.bat script on versions of Windows where it makes sense. [Yves] - Fixed the verbiage around choosing the correct make-alike on different platforms to suggest using 'perl -V:make'. [Suggested by anonymous user] 0.27_07 Wed Feb 1 20:07:45 CST 2006 - The notes() method now returns the new value when called with two arguments, just like when it's called with one argument. [Tyler MacDonald] - The notes() method now distinguishes among the values undef, 0, and the empty string, where previously it didn't. [Tyler MacDonald] - We now unshift(@INC) rather than push(@INC) for the directory where a build subclass lives, so that we're sure to pick up the right version and not some already-installed version. [perlmonkey] - The SIGNATURE file for version 0.27_06 (and I'm sure for lots of versions before that too!) was messed up, since we were modifying some files after signing. This has been band-aided for the time being by signing twice. [Reported by Chris Dolan] 0.27_06 Mon Jan 23 21:44:54 CST 2006 - Fixed an undefined-variable warning when building the META.yml file and the author hasn't used the 'module_name' mechanism. [Chris Dolan] - We should now work with recent (> 0.49) versions of YAML.pm when creating the META.yml file. [Yitzchak Scott-Thoennes] - The y_n() method now requires the default parameter, and the prompt() and y_n() methods have been improved with respect to how they behave/detect when there is no user to ask. We're now more consistent with MakeMaker, including respecting the PERL_MM_USE_DEFAULT environment variable. [Tyler MacDonald and Yitzchak Scott-Thoennes] - When building a README file using Pod::Text, work around a bug in Pod::Text 3.01, which expects Pod::Simple::parse_file to take input and output filehandles when it actually only takes an input filehandle. [Yitzchak Scott-Thoennes] 0.27_05 Thu Jan 12 17:39:21 CST 2006 - In t/common.pl, we were attempting to let the user's installed Test::More take precedence over ours, but getting thwarted by all the test scripts' loading Test::More beforehand. Fixed. [Spotted by Yitzchak Scott-Thoennes] - In various test scripts, we were outputting some strings that weren't strictly conformant with Test::Harness's expected input, though it didn't actually cause problems. Now we're more conformant, though not yet strict. [Spotted by Yitzchak Scott-Thoennes] 0.27_04 Fri Dec 23 10:43:34 CST 2005 - Removed experimental feature that extended the prerequisite system to apply ('requires', 'recommends', and 'conflicts') prereqs to all actions. Most of the internal extensiblity has been retained so that prereq types can easily be added, more selectively. - Added a 'prereq_report' action that shows the user a well-formatted list of all prerequisites, the versions required, and the versions actually installed. [David Wheeler] - Clarified the directory name that's created during the 'distdir' action. [Suggested by Tyler MacDonald] - Fixed a bug when creating the META.yml file without the help of YAML.pm - some common strings weren't quoted & escaped properly. Now only some uncommon ones are. [Spotted by Joshua ben Jore] - Fixed a bug in which an "UNINST=1" argument specified to a passthrough Makefile's "make install" wasn't actually seen by Module::Build. - Rather than dying when the Build script is run from the wrong directory, it now simply chdir()s into the right directory and keeps going. [Suggested by Dominique Quatravaux] - Added an "Examples on CPAN" section to the cookbook, with an initial entry pointing to John Peacock's SVN-Notify-Mirror distribution. - Add an invoked_action() method to return the name of the original action invoked by the user. - Add 'meta-spec' field to the generated META.yml file, including the version of the specification followed by the current Module::Build and the url where the specification can be found. - Introduced two actions, 'html' & 'manpages', that generate documentation for POD when the respective feature is enabled. The actions will generate the documents even if there is no set place to install to. However, if the actions are invoked as a dependency of another action (e.g. build), the documentation will only be built when there is a default or user-specified place to install to. - Added support for environment variable, 'MODULEBUILDRC', which can be used to specify the full path to an option file to use instead of the default location of ~/.modulebuildrc. A special undocumented setting of 'NONE' tells Module::Build not to load any user settings, so tests can be run without tainting from user options. - Documented and improved preliminary support for more Getopt::Long style options are supported, including boolean options (--verbose, --no-verbose), and use of hyphens in option names in addition to underscores. - The option to disable/enable reading of the ~/.modulebuildrc file is changed from 'skip_rcfile' to 'use_rcfile' - Allow the 'distmeta' action to continue when 'MANIFEST' is missing, omitting the generation of the 'provieds' field. [Steven Schubiger] - Fixed some failing regex from generated MANIFEST.SKIP file. - Fixed an edge case in $VERSION parsing where we thought a package() declaration was happening but it wasn't. [David Golden] - Added docs for the install_destination() and install_types() methods. 0.27_03 (Beta for 0.28) Mon Oct 10 11:19:23 EDT 2005 - We now use ExtUtils::CBuilder to do all compiling of C code (for example, when compiling XS modules). (This change actually occurred in 0.27_01, but it was mistakenly omitted from the Changes file.) - Fixed an issue on Win32 (and other case-tolerant non-case-preserving systems, possibly like VMS?) in which the current working directory would sometimes be reported with different case, fooling us into thinking that we were in the wrong directory. [David Golden] - The extra_compiler_flags setting was not actually being passed along to ExtUtils::CBuilder so it could pass it along to the compiler. Now it is. - The synonyms 'scripts' and 'prereq' for 'script_files' and 'requires' were broken in a previous version (0.27_01, probably), but now they're fixed. [David Golden] - Previously, we assumed that any custom subclass of Module::Build was located in _build/lib/. This is only true if the author used the subclass() method, though. We now use %INC to find where the custom subclass really is, so that we can "use lib" it. We also issue a warning if it seems to be outside the build directory. [Spotted by Peter Tandler] - Added a URL for each license type that we know about, which will appear as resources=>license: in the generated META.yml file. - If the user passes a no_index parameter to our constructor, we now pass that through when building the META.yml file. [Richard Soderberg, RT #9603] - A few more status messages can now be suppressed by using 'quiet' mode. [Dave Rolsky] - Added some more entries to the default MANIFEST.SKIP file. [Chris Dolan] - Our POD parser will now accept "AUTHORS" as well as "AUTHOR" when looking for the author list in a module. [David Wheeler] - When looking for the POD to auto-generate a README file, or for the AUTHOR or ABSTRACT for the distribution, we now also look for a *.pod with the same name as the *.pm file specified by 'version_from'. [David Golden] - The recommended dependency on ExtUtils::ParseXS has been moved into the "C_support" auto_feature. - When building XS files, we now pass the -DVERSION and -DXS_VERSION flags to the compiler. [Spotted by Jerry Hedden] - If a distribution has XS files and Module::Build has not been configured with the "C_support" feature, we now issue a warning. [Suggested by Jerry Hedden] - Added a dir_contains() method. - Some versions of MakeMaker, CPANPLUS, and/or PAUSE thought that a certain line of our code was declaring a $VERSION when we didn't intend to. The line has been obscurified so they won't think that anymore. [Jos Boumans, RT #14226] - Added the Apache, MIT, and Mozilla licenses to the list of licenses that this module knows about. [Bob Ippolito] - Fixed a pretty significant typo in the documentation for auto_features. [Spotted by Jonas B. Nielsen] - In order to aid people who want to do customization of the META.yml file, we've added a "metafile" property that can then be easily overridden in subclasses, changed do_create_meta_yml() to do_create_metafile(), and split out the code that actually generates the YAML into a new method, write_metafile(). [David Wheeler] - Fixed a couple of non-helpful behaviors with extra_compiler_flags and extra_linker_flags. These will automatically be run through split_like_shell() when given to new() as strings. - When the user doesn't have ExtUtils::ParseXS installed and we use the old 'xsubpp', the displayed command line for creating the .c file from the .xs file was missing its newline. Now it's got it. 0.27_02 (Beta for 0.28) Fri Jul 15 07:34:58 CDT 2005 - Provided initial support for the --prefix installation parameter, which acts like MakeMaker's PREFIX. It is still highly recommended NOT to use it when you could reasonably use --install_base or --install_path or --install_dest, but that's just because the way --prefix is designed is weird and unpredictable. Ultimately the choice rests with the installing user. [Patches by Michael Schwern and Rob Kinyon] - Fixed a bug in subclass() which prevented people from using it to subclass subclasses of Module::Build. [Chris Dolan] - Added a 'pure_install' action, which for the time being is identical to the 'install' action. [Jos Boumans] - Fixed a POD error in an L<http://...> tag. [Offer Kaye] - Note several options for automatically creating a new module dev tree. [Suggested by Eric Wilhelm] - Removed some hard-coded references to File::Spec::Unix in the creation of HTML docs, which should help that code work in more places, and help people not to panic when they look at it. [Spotted by Yves] - We now use Pod::Readme by default (instead of Pod::Text) to generate the README file when the 'create_readme' option is used. If Pod::Readme is not installed, we will still fall back to using Pod::Text. [Robert Rothenberg] - The values of the "prefix", "install_base", "install_path", and "install_dest" parameters can now begin with "~" or "~user", and we'll de-tilde-ify them by using glob(). - The (optional) auto-creation of the README and Makefile.PL files have been moved from the 'distdir' action to the 'distmeta' action. [David Golden] - When looking for a .modulebuildrc file, we now use a fancier method of trying to find the home directory, because $ENV{HOME} isn't a very cross-platform variable. [Robert Rothenberg] - We now memoize the output of the internal _default_INC() method, since it uses backticks and might be kind of slow. - When processing XS files, we now look for a typemap in lib/ as well as using the system's default typemap. [John Peacock] - The DESTDIR, PREFIX, and INSTALL_BASE arguments to "make install" are now supported for pass-through Makefiles (they've been supported for quite a while as arguments to "perl Makefile.PL"). [Requested by Guillaume Rousse] - Test::Harness has changed its output format in recent versions, which threw off one of our tests. We now allow for this different format. [Reported by Scott Godin] - Fixed an issue that prevented Module::Build from upgrading itself using its own API (which is how CPANPLUS uses it). There are still some issues with this solution, however. See ticket #13169 in rt.cpan.org. [Reported by Jos Boumans] - Fixed a fatal error that occurred when a distribution's author could not be determined from its POD nor from the call to Module::Build->new() in its Build.PL. See ticket #12318 in rt.cpan.org. [Reported by Jos Boumans] - Apparently on Windows and cygwin it's not possible to use the "-pi" switch to perl without a backup extension, so now we use ".bak" and remove the backup file when we're done. Thus the "dist" action for Module::Build itself can now be run on those platforms. [Yitzchak Scott-Thoennes] - Improved the handling of auto_features in the config_data access script. [Yitzchak Scott-Thoennes] 0.27_01 (Beta for 0.28) Fri Apr 15 21:12:57 CDT 2005 Backward-incompatible (but better) changes: * When using the 'install_base' option to choose a directory for installing everything, perl modules now go into lib/perl5/ instead of just lib/. It seems this is more consistent with people's expectations, and the way I had it before was a bit peculiar to the way I like things in my own home directory. [Michael Schwern] * When the user is using the 'install_base' option, scripts will now be installed by default in $install_base/bin/ rather than $install_base/script/ . [Jan Hudec and Michael Schwern] Major changes: - The auto_features mechanism will now re-evaluate dependencies every time feature() is called for an auto-feature, rather than freezing the success/failure value during 'perl Build.PL' and using that value for all eternity (or module update, whichever comes first). This applies to both $build->feature() and FooModule::ConfigData->feature() calls. [Requested by many] - Added the meta_add and meta_merge mechanisms, which let the module author add/merge arbitrary entries into the META.yml file. - Now reads per-action default options from '$ENV{HOME}/.modulebuildrc' if it exists. Command line options override anything set in the rc file. - We now use ExtUtils::CBuilder to do all compiling of C code (for example, when compiling XS modules). - The creation of Unix man pages is no longer a strict necessity - it has now been turned into an 'auto-feature' contingent on the presence of Pod::Man and a location specified for man pages to go. - A user-specified 'install_path' setting will now take precedence over an 'install_base' setting. This allows the user to use 'install_base' to set the base for all elements in one go, and then use 'install_path' to override specific paths or add paths for additional kinds of targets. - Split the main documentation from 'Module/Build.pm' into two sections. The user level documentation and overview remains in 'Module/Build.pm', while a new document, 'Module/Build/Authoring.pod', has been created for module authors. Minor changes: - new_from_context() was losing its arguments in some cases (and not because of inadequate training in forensic debate) - we now pass its arguments directly to the Build.PL script rather than merging them in afterwards. - Let resume() return an object blessed into the appropriate class if the user has provided a subclass, as specified by the 'build_class' property. This allows current() and new_from_context() to behave more like factory methods returning objects of the correct class based on context. [Ray Zimmerman] - Refactored methods relating to parsing perl module files for package, version, and pod data into a new class: Module::Build::ModuleInfo. It should not be considered part of Module::Build's API, because we may split it out entirely as a separate CPAN module that we depend on. - Added new method Module::Build::prepare_metadata() for authors to override in order to add custom fields to META.yml. - We now use Test::More for our regression tests. If the user doesn't have it installed, we include a copy in t/lib/ that we can use during testing. - When copying files in the 'distdir' action, set permissions to match the original files. [Julian Mehnle] - When adding files like META.yml to the MANIFEST, we now tell the user we're doing so by printing one of the "Added to MANIFEST: ..." lines. [Ron Savage] - Added a runtime_params() method, which lets a module author see which parameters were overridden by the user on the command line (or in whatever paradigm the user originally invoked Module::Build from). [David Wheeler] - Added the current_action() method, which, surprisingly, returns the name of the currently running action. [David Wheeler] - Added docs for run_perl_script(). - Added some stuff to the docs about why PREFIX is unsupported, and what to use instead. [Steve Purkis] - The simple get/set accessor methods for all the 'parameters' like verbose(), license(), etc. now have auto-generated documentation in Module/Build.pm. - Created a Cookbook entry for 'Adding new elements to the install process' - We now add META.yml to the MANIFEST when META.yml is created, not when MANIFEST is created. [Spotted by Ron Savage] - Added some additional patterns to the suggested MANIFEST.SKIP contents, and changed the docs so that we encourage the user to use the MANIFEST.SKIP. [Ron Savage] - Eliminated a redundant recipe from the Cookbook, now that there are some more extensive recipes on how to add stuff to the build/install sequences. - Eliminated an undefined-variable warning when testing under perl 5.005 - When building HTML documentation, 'html_backlink' and 'html_css' properties are now first-class properties, so they can be set from the command line. [Suggested by Sagar R. Shah] - Have script_files default to everything in bin. I believe this is the least surprising behavior. [Suggested by Michael Schwern] - If script_files is given a directory, consider each file in that directory tree as a script to be installed. This avoids having to remember to add to the script_files list every time you add a program. [Suggested by Michael Schwern] - We now only load Pod::Man when we actually need to build man pages. - We now make Test::Harness use our carefully-selected path to a perl executable regardless of Test::Harness's version. Previously we let it figure stuff out for itself if it was a reasonably modern version, but it's safer to make sure we're using the same perl everywhere. |
From: Ken W. <ke...@ma...> - 2006-04-28 03:23:50
|
On Apr 27, 2006, at 10:09 PM, Randy W. Sims wrote: > That's probably right. prompt() has always, AFAIK, used the empty > string '' as a default when unattended. I think this is the > behavior of MakeMaker also. The tests there were just to codify the > existing behavior. However, I believe that your correct in that if > it is running unattended and there is no default it should throw an > error. Cool. I'll see about putting the release together, then. Thanks. -Ken |
From: Randy W. S. <ml...@th...> - 2006-04-28 03:09:42
|
kwi...@cv... wrote: > Author: kwilliams > Date: Thu Apr 27 19:44:46 2006 > New Revision: 5978 > > Modified: > Module-Build/trunk/t/extend.t > > Log: > Unless I've overlooked a previous decision, prompt() should die > (rather than hang) when called in an unattended context with no > default. That's probably right. prompt() has always, AFAIK, used the empty string '' as a default when unattended. I think this is the behavior of MakeMaker also. The tests there were just to codify the existing behavior. However, I believe that your correct in that if it is running unattended and there is no default it should throw an error. Randy. |
From: Ken W. <ke...@ma...> - 2006-04-28 02:23:11
|
On Apr 27, 2006, at 6:22 PM, Randy W. Sims wrote: > At this point, I think I'd be very happy with that. Otherwise, > there might soon be a full revolt. I apologize to everyone for not > being more on top of things; it's difficult sometimes to manage > between God, family, work, this, and other responsibilities. I very > much envy those guys that can work full time jobs and still turn > out gobs of code every day. You're telling me! I can barely get my laptop opened these days. > Other than pulling the ask() method out along with it's > documentation, is there anything else I need to do before release? > I don't think we have any bugs that are more pressing than getting > a release out are there? I think that's about it too. I see you've already yanked out ask(), I'll poke & prod the distribution a little and if I don't see any obstacles I'll nonchalantly release 0.28 tonight. -Ken |
From: Randy W. S. <ml...@th...> - 2006-04-27 23:23:01
|
Ken Williams wrote: > > On Apr 24, 2006, at 12:35 AM, Randy W. Sims wrote: > >>> 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. >> >> Anyone have a chance to look over that patch? Does it do the right >> thing? Is it the behavior that was desired, and is it sensisble? > > I did have a look a couple of times, and I just keep feeling like we're > creating something too complicated. And that we're delaying 0.28 again. =( > > How's this proposal: let's keep the patch for ask() in the wings, and > release 0.28 without it. There's no real burning need for it, now that > y_n() and prompt() behave better in non-interactive mode. Hopefully we > can speed up the release schedule for things after 0.28, and we can plop > ask() into one of those releases when we're happy with it. At this point, I think I'd be very happy with that. Otherwise, there might soon be a full revolt. I apologize to everyone for not being more on top of things; it's difficult sometimes to manage between God, family, work, this, and other responsibilities. I very much envy those guys that can work full time jobs and still turn out gobs of code every day. Other than pulling the ask() method out along with it's documentation, is there anything else I need to do before release? I don't think we have any bugs that are more pressing than getting a release out are there? Randy. |
From: Ken W. <ke...@ma...> - 2006-04-27 02:48:42
|
Thanks, applied. -Ken On Apr 25, 2006, at 11:28 AM, Steve Hay wrote: > I've applied the following patch to bleadperl to fix some recent > smoke failures on Win32 following the upgrade of Test-Harness: > > http://public.activestate.com/cgi-bin/perlbrowse?patch=27960 |
From: Ken W. <ke...@ma...> - 2006-04-27 02:41:21
|
On Apr 24, 2006, at 12:35 AM, Randy W. Sims wrote: >> 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. > > Anyone have a chance to look over that patch? Does it do the right > thing? Is it the behavior that was desired, and is it sensisble? I did have a look a couple of times, and I just keep feeling like we're creating something too complicated. And that we're delaying 0.28 again. =( How's this proposal: let's keep the patch for ask() in the wings, and release 0.28 without it. There's no real burning need for it, now that y_n() and prompt() behave better in non-interactive mode. Hopefully we can speed up the release schedule for things after 0.28, and we can plop ask() into one of those releases when we're happy with it. -Ken |
From: Ken W. <ke...@ma...> - 2006-04-25 18:59:08
|
On Apr 25, 2006, at 8:17 AM, Adam Kennedy wrote: > Grr, stupid mailing list. > > I can subscribe to it, but it's not sending me messages. > Next time I see sourceforge I'll kick them. > > As long as it's a mini-language that can be parsed safely, then > having > > some expressiveness is fine. Most of where this will crop up is in > > module dependencies anyway, and the number of variables there is > > relatively contained: > > > > * platforms (in some set) > > * perl versions (in some set of ranges of versions) > > * module versions (in some set of ranges of versions) > > I think you underestimate the problem. > > Firstly, define "platform". Is it the processor arch? The string in > $^O? If it's 'Win32' then which Win32? Win95? Win98? What if I have > a dependency that needs something specifically on Windows XP only. > Or only works for Server versions of Win32. We would use the list of $^O strings and os_type() values found in Module/Build.pm . > > What about environment variables? Out of scope. > > There are already modules that add extra dependencies if $ENV > {AUTOMATED_TESTING} is true, so that under testing they can do more > thorough tests than would normally be done. Which is a bad idea. They'd handle that using dynamic_config, though. > > Then there's optional dependencies based on installed programs. Out of scope for this iteration, maybe for a future iteration. > > Module::Signature looks for the binary program 'gpg'. If it cannot > find it, it adds an extra 20 modules to the dep chain. Then it would have to use dynamic_config in this iteration of our mini-language. > > What version of Perl? 5.6 with threads, without threads? dynamic_config. We've got a set of predicates that we *know* are going to be useful. Let's not let the perfect be the enemy of the good here - we don't need to define the entire universe of helpful predicates before we make some of them available to users. > You just can't fit the richness required into a data structure, > which means you can't fit it into META.yml. > That's untrue, of course - perl code itself can be thought of as a data structure (the parse tree), or else things like your PPI would be impossible. What we're saying is that our data structure semantic doesn't need to be (and shouldn't be) Turing-complete. > There is no such thing as a single fixed "Win32 Platform". That's > not to say it isn't possible under some extremely tight controlled > conditions, just that it doesn't exist in the real world that CPAN > applies to. It's anything for which Module::Build->os_type() eq 'Windows'. > If someone were to come up with a suitably framed bet, I'd probably > be willing to put down serious money to say it is unsolvable. > > In Perl, dependencies are ultimately programmatic. You can only > approximate the dependencies in advance in an advisory way. Which > is what we do already in META.yml. Nobody's claiming we'll solve the world's dependency problems completely, but we know we can do better than we do now. -Ken |
From: Julian M. <ju...@me...> - 2006-04-25 16:50:12
|
Chris Dolan wrote: > On Apr 25, 2006, at 8:33 AM, demerphq wrote: > > On 4/25/06, Adam Kennedy <ad...@ph...> wrote: > > I have to say I pretty strongly agree with Adam here. A mini-language > > is a bad solution to this problem in comparison to simply generating > > the META.yml on the installation host. > > How about a 95% solution as a goal? Plan META.yml variants so that > 95% of all CPAN modules can be completely described by it. [...] The > other complicated 5% that Adam is worried about can use the flag that > indicates a dynamic config. That way, META.yml can be declared > definitive by the author for most of CPAN. [...] > > I posit that the mini-language outlined by David Golden on 2006-04-24 > is adequate for the 95% solution (or maybe even the 99% solution?) > > The problem with Yves' suggestion to generate META.yml on the > installation host, as I've said before, is that it renders META.yml > pointless. =46WIW, I agree with the 95% solution goal. Declaring the concept of stati= c=20 META.yml pointless because it doesn't cover 100% of the modules is=20 defeatistic. In fact, those other 5% of the modules should probably try=20 harder to simplify their dependencies. Sometimes it's far more robust to=20 simply always require some other module, even if under some obscure=20 circumstances you could go without it. |
From: Steve H. <ste...@uk...> - 2006-04-25 16:29:11
|
SSd2ZSBhcHBsaWVkIHRoZSBmb2xsb3dpbmcgcGF0Y2ggdG8gYmxlYWRwZXJsIHRvIGZpeCBzb21l IHJlY2VudCBzbW9rZSAKZmFpbHVyZXMgb24gV2luMzIgZm9sbG93aW5nIHRoZSB1cGdyYWRlIG9m IFRlc3QtSGFybmVzczoKCmh0dHA6Ly9wdWJsaWMuYWN0aXZlc3RhdGUuY29tL2NnaS1iaW4vcGVy bGJyb3dzZT9wYXRjaD0yNzk2MAoKCi0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLQ0KUmFkYW4gQ29tcHV0YXRpb25hbCBMdGQuDQoNClRoZSBpbmZvcm1hdGlv biBjb250YWluZWQgaW4gdGhpcyBtZXNzYWdlIGFuZCBhbnkgZmlsZXMgdHJhbnNtaXR0ZWQgd2l0 aCBpdCBhcmUgY29uZmlkZW50aWFsIGFuZCBpbnRlbmRlZCBmb3IgdGhlIGFkZHJlc3NlZShzKSBv bmx5LiBJZiB5b3UgaGF2ZSByZWNlaXZlZCB0aGlzIG1lc3NhZ2UgaW4gZXJyb3Igb3IgdGhlcmUg YXJlIGFueSBwcm9ibGVtcywgcGxlYXNlIG5vdGlmeSB0aGUgc2VuZGVyIGltbWVkaWF0ZWx5LiBU aGUgdW5hdXRob3JpemVkIHVzZSwgZGlzY2xvc3VyZSwgY29weWluZyBvciBhbHRlcmF0aW9uIG9m IHRoaXMgbWVzc2FnZSBpcyBzdHJpY3RseSBmb3JiaWRkZW4uIE5vdGUgdGhhdCBhbnkgdmlld3Mg b3Igb3BpbmlvbnMgcHJlc2VudGVkIGluIHRoaXMgZW1haWwgYXJlIHNvbGVseSB0aG9zZSBvZiB0 aGUgYXV0aG9yIGFuZCBkbyBub3QgbmVjZXNzYXJpbHkgcmVwcmVzZW50IHRob3NlIG9mIFJhZGFu IENvbXB1dGF0aW9uYWwgTHRkLiBUaGUgcmVjaXBpZW50KHMpIG9mIHRoaXMgbWVzc2FnZSBzaG91 bGQgY2hlY2sgaXQgYW5kIGFueSBhdHRhY2hlZCBmaWxlcyBmb3IgdmlydXNlczogUmFkYW4gQ29t cHV0YXRpb25hbCB3aWxsIGFjY2VwdCBubyBsaWFiaWxpdHkgZm9yIGFueSBkYW1hZ2UgY2F1c2Vk IGJ5IGFueSB2aXJ1cyB0cmFuc21pdHRlZCBieSB0aGlzIGVtYWlsLgo= |
From: David G. <da...@hy...> - 2006-04-25 15:38:55
|
Chris Dolan wrote: > The problem with Yves' suggestion to generate META.yml on the > installation host, as I've said before, is that it renders META.yml > pointless. The goal of META.yml is to create a non-executable source of > accurate metadata about a package. If you have to download the package > and run Build.PL to generate META.yml, then why bother using META.yml? > In that case just use Build.PL itself. This was the point I was getting at. Otherwise, every indexer will need to run in a chroot jail and will only have valid information for the configuration of the indexer. That said, Adam's list of special cases is formidable, though I'm not sure that every eventuality needs to be supported. I'd be happy if it covered 80% of cases. Is there a reference to the existing mini-language proposal? As an intermediate measure, what do people think about adding a "may_require" field to the META.yml spec as something in between "requires" and "recommends". This would be for things that might get required depending on local configuration. For a mix of human and indexer useful info, it could function like recommends, with a text description and a list (apologies if my YAML is poor): may_require: - gpg not available: - Module::A - Module::B - etc - older Win32 (e.g. Win95, Win98): - Win32::C - Win32::D Regards, David Golden |
From: Chris D. <ch...@cl...> - 2006-04-25 14:21:31
|
On Apr 25, 2006, at 8:33 AM, demerphq wrote: > On 4/25/06, Adam Kennedy <ad...@ph...> wrote: > I have to say I pretty strongly agree with Adam here. A mini-language > is a bad solution to this problem in comparison to simply generating > the META.yml on the installation host. How about a 95% solution as a goal? Plan META.yml variants so that 95% of all CPAN modules can be completely described by it. If that requires a mini-language that supports the various $^O strings and $^V versions, then so be it. The other complicated 5% that Adam is worried about can use the flag that indicates a dynamic config. That way, META.yml can be declared definitive by the author for most of CPAN. The minority can then declare that you need to run Makefile.PL/ Build.PL to get the definitive metadata. That way, tools that are not allowed to execute code can still be useful on the majority of CPAN. I posit that the mini-language outlined by David Golden on 2006-04-24 is adequate for the 95% solution (or maybe even the 99% solution?) The problem with Yves' suggestion to generate META.yml on the installation host, as I've said before, is that it renders META.yml pointless. The goal of META.yml is to create a non-executable source of accurate metadata about a package. If you have to download the package and run Build.PL to generate META.yml, then why bother using META.yml? In that case just use Build.PL itself. The problem with generating a naive META.yml on the author's computer is that you often can't tell which are optional dependencies and which are required and which platforms are excluded (like the whole Win32:: tree). I believe that an author-generated META.yml with limited conditional support and a "non-definitive" flag to support the rest will satisfy the needs of the vast majority of uses for META.yml. Chris -- Chris Dolan, Software Developer, Clotho Advanced Media Inc. 608-294-7900, fax 294-7025, 1435 E Main St, Madison WI 53703 vCard: http://www.chrisdolan.net/ChrisDolan.vcf Clotho Advanced Media, Inc. - Creators of MediaLandscape Software (http://www.media-landscape.com/) and partners in the revolutionary Croquet project (http://www.opencroquet.org/) |
From: demerphq <dem...@gm...> - 2006-04-25 13:40:16
|
On 4/25/06, Adam Kennedy <ad...@ph...> wrote: > Grr, stupid mailing list. > > I can subscribe to it, but it's not sending me messages. > > > As long as it's a mini-language that can be parsed safely, then having > > some expressiveness is fine. Most of where this will crop up is in > > module dependencies anyway, and the number of variables there is > > relatively contained: > > > > * platforms (in some set) > > * perl versions (in some set of ranges of versions) > > * module versions (in some set of ranges of versions) > > I think you underestimate the problem. > > Firstly, define "platform". Is it the processor arch? The string in $^O? > If it's 'Win32' then which Win32? Win95? Win98? What if I have a > dependency that needs something specifically on Windows XP only. Or only > works for Server versions of Win32. > > What about environment variables? > > There are already modules that add extra dependencies if > $ENV{AUTOMATED_TESTING} is true, so that under testing they can do more > thorough tests than would normally be done. > > Then there's optional dependencies based on installed programs. > > Module::Signature looks for the binary program 'gpg'. If it cannot find > it, it adds an extra 20 modules to the dep chain. > > What version of Perl? 5.6 with threads, without threads? > > So you need branch logic, you need to interact with the environment > outside of the process (at least in a read-only manner) so you can't > sandbox whatever is running the logic, you probably need a full range of > boolean logic operators, which means you also need precedence support, > and you are probably going to want subsections (i.e. subroutines) and > probably inclusion of other files for reuse (i.e. modules) and you will > inevitably want something like loops. Also, some of these are going to > be host-specific, so you STILL can't run them anywhere but the current > machine. > > You just can't fit the richness required into a data structure, which > means you can't fit it into META.yml. > > The alternative of a mini-language is dangerous. I've seen the only one > proposed so far and it is a very heavy language. > > With META.yml on one side (data) and Makefile.PL on the other (code) I > have trouble seeing that you can find ANY place in the middle that is > usefully complete. I'd love to be convinced otherwise, but I'd like to > see someone demonstrate a WORKING solution that can handle even the > Bundle::CPAN subset of module before you commit to incorporating it. > > > Use case: Create an index of all dependencies for all distributions on > > the Win32 platform without running Makefile|Build.PL for all > > distributions. (E.g. for a potential "CP-PAN" i.e. "CamelPack-PAN") > > There is no such thing as a single fixed "Win32 Platform". That's not to > say it isn't possible under some extremely tight controlled conditions, > just that it doesn't exist in the real world that CPAN applies to. > > If someone were to come up with a suitably framed bet, I'd probably be > willing to put down serious money to say it is unsolvable. > > In Perl, dependencies are ultimately programmatic. You can only > approximate the dependencies in advance in an advisory way. Which is > what we do already in META.yml. I have to say I pretty strongly agree with Adam here. A mini-language is a bad solution to this problem in comparison to simply generating the META.yml on the installation host. Yves -- perl -Mre=3Ddebug -e "/just|another|perl|hacker/" |
From: Adam K. <ad...@ph...> - 2006-04-25 13:20:04
|
Grr, stupid mailing list. I can subscribe to it, but it's not sending me messages. > As long as it's a mini-language that can be parsed safely, then having > some expressiveness is fine. Most of where this will crop up is in > module dependencies anyway, and the number of variables there is > relatively contained: > > * platforms (in some set) > * perl versions (in some set of ranges of versions) > * module versions (in some set of ranges of versions) I think you underestimate the problem. Firstly, define "platform". Is it the processor arch? The string in $^O? If it's 'Win32' then which Win32? Win95? Win98? What if I have a dependency that needs something specifically on Windows XP only. Or only works for Server versions of Win32. What about environment variables? There are already modules that add extra dependencies if $ENV{AUTOMATED_TESTING} is true, so that under testing they can do more thorough tests than would normally be done. Then there's optional dependencies based on installed programs. Module::Signature looks for the binary program 'gpg'. If it cannot find it, it adds an extra 20 modules to the dep chain. What version of Perl? 5.6 with threads, without threads? So you need branch logic, you need to interact with the environment outside of the process (at least in a read-only manner) so you can't sandbox whatever is running the logic, you probably need a full range of boolean logic operators, which means you also need precedence support, and you are probably going to want subsections (i.e. subroutines) and probably inclusion of other files for reuse (i.e. modules) and you will inevitably want something like loops. Also, some of these are going to be host-specific, so you STILL can't run them anywhere but the current machine. You just can't fit the richness required into a data structure, which means you can't fit it into META.yml. The alternative of a mini-language is dangerous. I've seen the only one proposed so far and it is a very heavy language. With META.yml on one side (data) and Makefile.PL on the other (code) I have trouble seeing that you can find ANY place in the middle that is usefully complete. I'd love to be convinced otherwise, but I'd like to see someone demonstrate a WORKING solution that can handle even the Bundle::CPAN subset of module before you commit to incorporating it. > Use case: Create an index of all dependencies for all distributions on > the Win32 platform without running Makefile|Build.PL for all > distributions. (E.g. for a potential "CP-PAN" i.e. "CamelPack-PAN") There is no such thing as a single fixed "Win32 Platform". That's not to say it isn't possible under some extremely tight controlled conditions, just that it doesn't exist in the real world that CPAN applies to. If someone were to come up with a suitably framed bet, I'd probably be willing to put down serious money to say it is unsolvable. In Perl, dependencies are ultimately programmatic. You can only approximate the dependencies in advance in an advisory way. Which is what we do already in META.yml. Adam K |
From: Ken W. <ke...@ma...> - 2006-04-25 12:37:05
|
On Apr 23, 2006, at 12:13 PM, Julian Mehnle wrote: > > So apparently -x always returns true for root, and (mode & 0100) for > non-root. > > Also: > > | $ sudo -u julian ./f--x------ > | $ sudo -u julian ./f--------x > | sudo: unable to execute ./f--------x: Permission denied > | $ sudo ./f--x------ > | $ sudo ./f--------x > | $ > > If a file really is 0445 (0455), then I think it is reasonably safe to > assume that either ug-x (u-x) was _deliberately_ set or that o+x (go > +x) > was _accidentally_ set, and that therefore "not x" should be > assumed. IOW, > it should be reasonably safe to consider the user x bit authoritative. > > Thus Module::Build should use -x for the executable check. However > since > root (e.g. during `Build install`) always sees files as "x" if > _any_ x bit > is set, M::B would have to emulate -x's non-root behavior: > > my $mode = 0444 | ( (stat($file))[2] & 0100 ? 0111 : 0 ); Well, the 0100 mask isn't quite right I think, because the user might not be the owner. In this special case perhaps we can count on the user being the owner of files in blib/ though, I'm not sure. Certainly it would be true on *nix. The point about root & -x is certainly true, I hadn't thought about that. We'll have to fix that. -Ken |
From: Ken W. <ke...@ma...> - 2006-04-25 03:07:21
|
On Apr 24, 2006, at 11:49 AM, David Golden wrote: > Adam Kennedy wrote: >> A META.yml file is packed up with the dist for the convenience of >> larger systems, and META.yml in this case is known to only be an >> approximation. > > I think it's for the convenience of telling indexers about: > > (a) metadata (e.g. version numbers, dependencies) that would > otherwise require them to run (potentially unsafe) code on all > distributions submitted > > (b) metadata about the distribution structure, e.g. files that > should/shouldn't be indexed (c) Simple metadata like author name, distribution name, abstract, support URLs, license, and so on, that would otherwise be buried in various places in the tarball and (d) Letting humans browse this same data too >> When true, the CPAN client should be aware it needs to run the >> installer script first, which will localise the META.yml content, >> to get a definitive result for that environment. > > That seems redundant -- I think the installers can notify clients > of dependencies directly without a new META.yml being created. > Once an installer has committed to running Makefile|Build.PL, the > META.yml is irrelevant. Yeah, the META.yml is really not the right place for installers to be looking for dependencies. A better place is _build/prereq after the Build.PL is run. > >> The problem with doing some sort of optional feature is that it >> introduces branch logic into your data structures. >> So you need a way to describe the branch... platform => 'Win32'... >> [ platform => 'Win32', perl => '> 5.005 || < 5.008004' ], and so >> on and so on. >> But because you are trying to express logic (code) as data, you >> are always going to cases where you need just that bit more syntax >> and flexibility, until before you know it you have invented your >> own new mini-language, and well, then we might as well use Perl. > > As long as it's a mini-language that can be parsed safely, then > having some expressiveness is fine. Most of where this will crop > up is in module dependencies anyway, and the number of variables > there is relatively contained: > > * platforms (in some set) > * perl versions (in some set of ranges of versions) > * module versions (in some set of ranges of versions) > > The logic is pretty simple, too. If a given set of those > conditions above is true, then a given set of dependencies exist > (which can be expressed again as a set of ranges of versions). > >> But then of course we have Perl inside META.yml, and we're back to >> square 1. > > A mini language for that shouldn't be too challenging to write and > parse. Yeah, by no means should we ever put Perl inside the META.yml. That would be serious trouble. We'd be back to square zero as far as I'm concerned. The mini-language is something we do plan to do, we've made some headway in the past but it's waiting for some other more pressing issues. > Use case: Create an index of all dependencies for all distributions > on the Win32 platform without running Makefile|Build.PL for all > distributions. (E.g. for a potential "CP-PAN" i.e. "CamelPack-PAN") > > Personally, I think that YAML is complete overkill for CPAN > distribution metadata. Its major advantage seems to be that it's > easily read by humans. It's definitely overkill, but the small subset of YAML that we actually use is a pretty good fit. Human readability is a pretty huge factor IMO. And now we have a simple YAML generator bundled with M::B too, so we don't need to worry about YAML's dependency chain. -Ken |
From: Ken W. <ke...@ma...> - 2006-04-24 17:33:44
|
On Apr 24, 2006, at 12:44 AM, Randy W. Sims wrote: > I'm not sure what to do about this one. > > 1.) We can strictly record the @INC at the time 'Build.PL' is run, > we can check it against @INC when './Build' is run, and if it is > different, we can warn the user. CON: User cannot take advantage of > changes to @INC /after/ running 'Build.PL' without re-running it. > > 2.) We can add any changes to @INC to the beginning or the end of > the original @INC. This will allow the user to add entries either > with -I option or by setting env PERL5LIB, etc. CON: Do the uniq > entries go at the beginning or end; there is no clear choice. > > I'm leaning heavily on (1) at the moment because it is well defined > and we alread warn about other changes in the environment. Also, I > don't see much advantage to have a differing @INC between > 'Build.PL' and './Build', so nothing is lost. The original use case for all this @INC munging is that when the author puts a "use lib" or a "push @INC" or whatever in their Build.PL script, the effect on @INC ought to be seen in the Build script too. That means that a strict interpretation of (1) isn't workable. It would also break backwards compatibility with existing Build.PL scripts. If we can't figure out some smart version of (2) that we like, we should just defer this to a later version and not try to fix it for 0.28. -Ken |
From: David G. <da...@hy...> - 2006-04-24 16:49:46
|
Adam Kennedy wrote: > A META.yml file is packed up with the dist for the convenience of larger > systems, and META.yml in this case is known to only be an approximation. I think it's for the convenience of telling indexers about: (a) metadata (e.g. version numbers, dependencies) that would otherwise require them to run (potentially unsafe) code on all distributions submitted (b) metadata about the distribution structure, e.g. files that should/shouldn't be indexed > When true, the CPAN client should be aware it needs to run the installer > script first, which will localise the META.yml content, to get a > definitive result for that environment. That seems redundant -- I think the installers can notify clients of dependencies directly without a new META.yml being created. Once an installer has committed to running Makefile|Build.PL, the META.yml is irrelevant. > The problem with doing some sort of optional feature is that it > introduces branch logic into your data structures. > > So you need a way to describe the branch... platform => 'Win32'... [ > platform => 'Win32', perl => '> 5.005 || < 5.008004' ], and so on and so > on. > > But because you are trying to express logic (code) as data, you are > always going to cases where you need just that bit more syntax and > flexibility, until before you know it you have invented your own new > mini-language, and well, then we might as well use Perl. As long as it's a mini-language that can be parsed safely, then having some expressiveness is fine. Most of where this will crop up is in module dependencies anyway, and the number of variables there is relatively contained: * platforms (in some set) * perl versions (in some set of ranges of versions) * module versions (in some set of ranges of versions) The logic is pretty simple, too. If a given set of those conditions above is true, then a given set of dependencies exist (which can be expressed again as a set of ranges of versions). > But then of course we have Perl inside META.yml, and we're back to > square 1. A mini language for that shouldn't be too challenging to write and parse. > I don't know whether or not it was planned, but the current situation, > with a flagged-imperfect uploaded META.yml, which is localised at > Makefile|Build.PL-time quite comfortably covers 100% of all use cases > I'm aware of. Use case: Create an index of all dependencies for all distributions on the Win32 platform without running Makefile|Build.PL for all distributions. (E.g. for a potential "CP-PAN" i.e. "CamelPack-PAN") Personally, I think that YAML is complete overkill for CPAN distribution metadata. Its major advantage seems to be that it's easily read by humans. Regards, David Golden |
From: Adam K. <ad...@ph...> - 2006-04-24 16:09:55
|
Hi folks I was asked to point you in the direction of the following http://use.perl.org/~Alias/journal/29427 If it fits what you want and you'd like to embed it, you are welcome to hack on it directly. http://use.perl.org/~Alias/journal/29327 Also, is there somewhere that has a nntp server for this list, like you can get for most of the other Perl mailing lists? Oh, and there seems to be some confusion about the meaning of META.yml? As I understand it from doing CPAN.pm and Module::Install stuff, META.yml is intrinsically dynamic and platform dependant, where "platform" actually means environment, and is going to be different for every single host. A META.yml file is packed up with the dist for the convenience of larger systems, and META.yml in this case is known to only be an approximation. This is enforced by the dynamic_config flag, which defaults to true. When true, the CPAN client should be aware it needs to run the installer script first, which will localise the META.yml content, to get a definitive result for that environment. Of course, in the case where dynamic_config is explicitly set to false, the installer is advertising (via inserting the entry at dist-time) that the META.yml will not change when the installer is run, and so the client is free to shortcut the dependency installation if it wishes. BOTH of these situations (the version in the tarball and the version post-installer.PL) have their uses in a few different cases, and both really need to be retained. The problem with doing some sort of optional feature is that it introduces branch logic into your data structures. So you need a way to describe the branch... platform => 'Win32'... [ platform => 'Win32', perl => '> 5.005 || < 5.008004' ], and so on and so on. But because you are trying to express logic (code) as data, you are always going to cases where you need just that bit more syntax and flexibility, until before you know it you have invented your own new mini-language, and well, then we might as well use Perl. But then of course we have Perl inside META.yml, and we're back to square 1. I don't know whether or not it was planned, but the current situation, with a flagged-imperfect uploaded META.yml, which is localised at Makefile|Build.PL-time quite comfortably covers 100% of all use cases I'm aware of. I'm more than happy the way things are in this case. Adam K |
From: Randy W. S. <ml...@th...> - 2006-04-24 05:44:42
|
Ken Williams wrote: > > 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? I'm not sure what to do about this one. 1.) We can strictly record the @INC at the time 'Build.PL' is run, we can check it against @INC when './Build' is run, and if it is different, we can warn the user. CON: User cannot take advantage of changes to @INC /after/ running 'Build.PL' without re-running it. 2.) We can add any changes to @INC to the beginning or the end of the original @INC. This will allow the user to add entries either with -I option or by setting env PERL5LIB, etc. CON: Do the uniq entries go at the beginning or end; there is no clear choice. I'm leaning heavily on (1) at the moment because it is well defined and we alread warn about other changes in the environment. Also, I don't see much advantage to have a differing @INC between 'Build.PL' and './Build', so nothing is lost. Randy. |
From: Randy W. S. <ml...@th...> - 2006-04-24 05:35:27
|
Randy W. Sims wrote: > 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. Anyone have a chance to look over that patch? Does it do the right thing? Is it the behavior that was desired, and is it sensisble? Randy. |
From: Julian M. <ju...@me...> - 2006-04-23 17:13:37
|
Ken Williams wrote: > demerphq wrote: > > Randy W. Sims wrote: > > > Ken Williams wrote: > > > > I wonder whether we should check for executability with "-x $file" > > > > rather than "(stat $file)[2] & 0111". Besides being simpler, it > > > > seems like it might DTRT on more platforms, where stat values might > > > > be nontrustworthy. > > > > > > You mean like so: > > > > > > $mode =3D 0444 | ( -x $file ? 0111 : 0 ); > > > > Seems to me that if -x and stat with the appropriate mask arent > > returning the same thing you have a bug in Perl. > > Not necessarily. On Unix, for example, if the permissions on a file > you own are 0445, then "(stat $file)[2] & 0111" will return true but > "-x $file" will return false. Maybe that means we're not using "the > appropriate mask", but what would an appropriate mask be in all the > situations we care about? Probably none exists. Sorry for my late comment on this. `perldoc -f -x` is interesting: | The interpretation of the file permission operators "-r", "-R", "-w", | "-W", "-x", and "-X" is by default based solely on the mode of the file | and the uids and gids of the user. There may be other reasons you can't | actually read, write, or execute the file. Such reasons may be for | example network filesystem access controls, ACLs (access control lists), | read-only filesystems, and unrecognized executable formats. |=20 | Also note that, for the superuser on the local filesystems, the "-r", | "-R", "-w", and "-W" tests always return 1, and "-x" and "-X" return 1 | if any execute bit is set in the mode. Scripts run by the superuser may | thus need to do a stat() to determine the actual mode of the file, or | temporarily set their effective uid to something else. On Linux/Unix: | $ ls -go --time-style=3D+ | total 0 | -rw-r--r-- 1 0 f--------- | -rw-r--r-x 1 0 f--------x | -rw-r-xr-- 1 0 f-----x--- | -rw-r-xr-x 1 0 f-----x--x | -rwxr--r-- 1 0 f--x------ | -rwxr--r-x 1 0 f--x-----x | -rwxr-xr-x 1 0 f--x--x--x | $ perl -e 'printf("%s: -x =3D %s\n", $_, -x $_ || "0") for @ARGV' * | f---------: -x =3D 0 | f--------x: -x =3D 0 | f-----x---: -x =3D 0 | f-----x--x: -x =3D 0 | f--x------: -x =3D 1 | f--x-----x: -x =3D 1 | f--x--x--x: -x =3D 1 | $ sudo perl -e 'printf("%s: -x =3D %s\n", $_, -x $_ || "0") for @ARGV' * | f---------: -x =3D 0 | f--------x: -x =3D 1 | f-----x---: -x =3D 1 | f-----x--x: -x =3D 1 | f--x------: -x =3D 1 | f--x-----x: -x =3D 1 | f--x--x--x: -x =3D 1 So apparently -x always returns true for root, and (mode & 0100) for=20 non-root. Also: | $ sudo -u julian ./f--x------ | $ sudo -u julian ./f--------x | sudo: unable to execute ./f--------x: Permission denied | $ sudo ./f--x------ | $ sudo ./f--------x | $ If a file really is 0445 (0455), then I think it is reasonably safe to=20 assume that either ug-x (u-x) was _deliberately_ set or that o+x (go+x)=20 was _accidentally_ set, and that therefore "not x" should be assumed. IOW,= =20 it should be reasonably safe to consider the user x bit authoritative. Thus Module::Build should use -x for the executable check. However since=20 root (e.g. during `Build install`) always sees files as "x" if _any_ x bit= =20 is set, M::B would have to emulate -x's non-root behavior: my $mode =3D 0444 | ( (stat($file))[2] & 0100 ? 0111 : 0 ); |
From: Julian M. <ju...@me...> - 2006-04-21 18:09:00
|
Hi Ken and Randy, I'm curious, what's the planned schedule for the 0.28 release? Julian. |
From: Steven S. <sch...@cp...> - 2006-04-20 20:56:44
|
On Thu, Apr 20, 2006 at 07:29:42PM +0000, Julian Mehnle wrote: > That's what the "distcheck" action is for, but perhaps it is a good idea to > automatically run a "distcheck" on the "dist" action? I concur. I'm afraid I'm unable to provide a patch against the latest version in the svn.perl.org repository; the patch originated from 0.27_10 (and may require some copy & paste magic). --- Base.pm.orig Thu Apr 20 22:38:42 2006 +++ Base.pm Thu Apr 20 22:39:12 2006 @@ -2713,6 +2713,8 @@ $self->make_tarball($dist_dir); $self->delete_filetree($dist_dir); + + $self->_call_action('distcheck'); } sub ACTION_distcheck { -- Hi no Haru wo sasugani Turu no Ayumi kana |
From: Julian M. <ju...@me...> - 2006-04-20 19:29:54
|
Steven Schubiger wrote: > 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? Yes, this is intentional. Files should never implicitly be added to the=20 manifest. > 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?=20 That's what the "distcheck" action is for, but perhaps it is a good idea to= =20 automatically run a "distcheck" on the "dist" action? |