Thread: Re: [Module::Build] Making 0.28 a reality (Page 2)
Status: Beta
Brought to you by:
kwilliams
Menu
▾
▴
module-build-general
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-28 19:18:13
|
On Mon, Mar 20, 2006 at 11:09:39PM -0500, David Golden wrote: > John Peacock wrote: > >I'm not Ken (nor do I play him on TV), but I'd actually suggest moving > >the code to a new module Module::Build::YAML, both for clarity (to > >separate the code for easier maintenance) as well as easier replacement > >(M::B can try to use YAML and only if it isn't found switch to using > >M::B::YAML instead). It may be that at some time in the future it would > >be useful to be able to /read/ YAML data (which requires the full YAML > >distro) instead of just /writing/ YAML (which the compatibility layer > >can handle nicely). > > Any chance this could be generalized further to handle all the YAML that > CPAN.pm needs and free us from the tyranny of YAML prerequisites? > > Module::MetaYAML? The point of not just requiring the "real" YAML is to keep a low-level module-builder (Module::Build) from requiring other distributions. This doesn't apply to CPAN, and separating out a Module::MetaYAML would defeat this purpose for MB. |
|
From: David G. <da...@hy...> - 2006-03-28 20:17:17
|
Yitzchak Scott-Thoennes wrote: > On Mon, Mar 20, 2006 at 11:09:39PM -0500, David Golden wrote: >> John Peacock wrote: >>> I'm not Ken (nor do I play him on TV), but I'd actually suggest moving >>> the code to a new module Module::Build::YAML, both for clarity (to >>> separate the code for easier maintenance) as well as easier replacement >>> (M::B can try to use YAML and only if it isn't found switch to using >>> M::B::YAML instead). It may be that at some time in the future it would >>> be useful to be able to /read/ YAML data (which requires the full YAML >>> distro) instead of just /writing/ YAML (which the compatibility layer >>> can handle nicely). >> Any chance this could be generalized further to handle all the YAML that >> CPAN.pm needs and free us from the tyranny of YAML prerequisites? >> >> Module::MetaYAML? > > The point of not just requiring the "real" YAML is to keep a low-level > module-builder (Module::Build) from requiring other distributions. > This doesn't apply to CPAN, and separating out a Module::MetaYAML > would defeat this purpose for MB. However, the latest Bundle::CPAN includes YAML, which uses Module::Install, requires 5.6.1 or better and build_requires Test::Base, which itself requires Spiffy. So... when CPAN tells someone their CPAN is out of date and to upgrade with Bundle::CPAN or when someone wants to upgrade CPAN for some other reason -- for example, for better compatibility with Module::Build -- they're in for a world of hurt if any of the ballooning dependencies fail to build using the already installed CPAN/installer toolchain. It doesn't really matter if M::B is self-contained or not if the other parts of the toolchain are fouled up. David |
|
From: Ken W. <ke...@ma...> - 2006-03-28 23:57:57
|
On Mar 28, 2006, at 2:16 PM, David Golden wrote: > However, the latest Bundle::CPAN includes YAML, which uses > Module::Install, requires 5.6.1 or better and build_requires > Test::Base, which itself requires Spiffy. > > So... when CPAN tells someone their CPAN is out of date and to > upgrade with Bundle::CPAN or when someone wants to upgrade CPAN for > some other reason -- for example, for better compatibility with > Module::Build -- they're in for a world of hurt if any of the > ballooning dependencies fail to build using the already installed > CPAN/installer toolchain. I agree that this dependency chain is messed up and needs a solution. Personally I'm leaving it to those folks to work out, though. The tool we need for M::B is different than the one they need. > > It doesn't really matter if M::B is self-contained or not if the > other parts of the toolchain are fouled up. No, it does matter. -Ken |
|
From: David G. <da...@hy...> - 2006-03-29 04:11:26
|
Ken Williams wrote: > > On Mar 28, 2006, at 2:16 PM, David Golden wrote: >> >> It doesn't really matter if M::B is self-contained or not if the other >> parts of the toolchain are fouled up. > > No, it does matter. Well, yes and no. Why are useful bits like ExtUtils::Manifest split off? Why are we trying to get ExtUtils::Install split off from ExtUtils::MakeMaker? I don't think that all of M::B functionality has to be contained within the M::B distribution -- well packaged, reusable dependencies should be OK. My point (in response to something else in the email thread) was that bundling stuff into M::B to minimize dependencies isn't enough. I'd rather see a Module::MetaYaml split off like ExtUtils::Manifest if it could become the nucleus of something that might grow to help other parts of the toolchain rather than keeping it "locked up" inside the Module::Build distribution. To the broader point Ken made, I totally agree that M::B doesn't need to solve the rest of the toolchain's problems. David Golden |
|
From: Stephen A. <spa...@gm...> - 2006-03-29 04:57:35
|
> Well, yes and no. Why are useful bits like ExtUtils::Manifest split
> off? Why are we trying to get ExtUtils::Install split off from
> ExtUtils::MakeMaker? I don't think that all of M::B functionality has
> to be contained within the M::B distribution -- well packaged, reusable
> dependencies should be OK. My point (in response to something else in
> the email thread) was that bundling stuff into M::B to minimize
> dependencies isn't enough.
...
> I'd rather see a Module::MetaYaml split off like ExtUtils::Manifest if
...
> David Golden
Hi,
The two full implementations of YAML in perl are YAML (i.e. YAML.pm)
and YAML::Syck. Neither of them has significant other dependencies.
YAML - build_requires: Test::Base: 0.49
requires: perl 5.6.1
YAML::Syck - build requires a C compiler
requires: perl 5.003
http://search.cpan.org/src/INGY/YAML-0.58/META.yml
http://search.cpan.org/src/AUTRIJUS/YAML-Syck-0.38/META.yml
What is not "well packaged" about these two distributions?
Is the reason Module::Build can't depend on YAML because it depends on
perl 5.6.1
and Module::Build seeks to support (depend on only) perl 5.5.3?
Module::Build has the following dependencies.
requires:
Cwd: 0
Data::Dumper: 0
ExtUtils::Install: 0
ExtUtils::Manifest: 0
ExtUtils::Mkbootstrap: 0
File::Basename: 0
File::Compare: 0
File::Copy: 0
File::Find: 0
File::Path: 0
File::Spec: 0.82
Getopt::Long: 0
IO::File: 0
Test::Harness: 0
Text::ParseWords: 0
perl: 5.005_03
build_requires:
Test::More: 0
recommends:
Archive::Tar: 1.08
ExtUtils::Install: 0.3
Module::Signature: 0.21
Pod::Readme: 0.04
http://search.cpan.org/src/KWILLIAMS/Module-Build-0.27_09/META.yml
The only reason to have *another* external YAML distribution is to
have one which
has even fewer dependencies (i.e. perl 5.005_03 aka 5.5.3, no C compiler).
Some possible names for the module...
YAML::Simple
YAML::Portable
If a YAML::Simple existed (which implemented a sufficient subset of
the YAML spec),
would this significantly improve the dependency characteristics of the
tool chain?
Stephen
|
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-29 07:34:14
|
On Tue, Mar 28, 2006 at 11:57:24PM -0500, Stephen Adkins wrote: > Is the reason Module::Build can't depend on YAML because it depends on > perl 5.6.1 > and Module::Build seeks to support (depend on only) perl 5.5.3? No. > Module::Build has the following dependencies. > > requires: > Cwd: 0 > Data::Dumper: 0 > ExtUtils::Install: 0 > ExtUtils::Manifest: 0 > ExtUtils::Mkbootstrap: 0 > File::Basename: 0 > File::Compare: 0 > File::Copy: 0 > File::Find: 0 > File::Path: 0 > File::Spec: 0.82 > Getopt::Long: 0 > IO::File: 0 > Test::Harness: 0 > Text::ParseWords: 0 > perl: 5.005_03 > build_requires: > Test::More: 0 > recommends: > Archive::Tar: 1.08 > ExtUtils::Install: 0.3 > Module::Signature: 0.21 > Pod::Readme: 0.04 > > http://search.cpan.org/src/KWILLIAMS/Module-Build-0.27_09/META.yml Cwd was first released with perl 5 Data::Dumper was first released with perl 5.005 ExtUtils::Install was first released with perl 5.002 ExtUtils::Manifest was first released with perl 5.001 ExtUtils::Mkbootstrap was first released with perl 5.001 File::Basename was first released with perl 5 File::Compare was first released with perl 5.004 File::Copy was first released with perl 5.002 File::Find was first released with perl 5 File::Path was first released with perl 5.001 File::Spec was first released with perl 5.005 Getopt::Long was first released with perl 5 IO::File was first released with perl 5.00307 Test::Harness was first released with perl 5 Text::ParseWords was first released with perl 5 Test::More was first released with perl 5.007003 That build_requires on Test::More is erroneous, since it is bundled in the distribution. It should be removed: (untested) --- Build.PL.orig 2006-01-20 11:29:18.898665000 -0800 +++ Build.PL 2006-03-28 23:32:38.812500000 -0800 @@ -43,9 +43,6 @@ 'Pod::Readme' => 0.04, 'Module::Signature' => 0.21, }, - build_requires => { - 'Test::More' => 0, - }, sign => 1, create_readme => 1, > The only reason to have *another* external YAML distribution is to > have one which > has even fewer dependencies (i.e. perl 5.005_03 aka 5.5.3, no C compiler). > > Some possible names for the module... > > YAML::Simple > YAML::Portable > > If a YAML::Simple existed (which implemented a sufficient subset of > the YAML spec), > would this significantly improve the dependency characteristics of the > tool chain? If possible, it would be better to make YAML itself work on 5.005_03 than to create a YAML::Simple. But neither satisfies the goal of having M::B have no non-core dependencies. |
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-29 07:49:19
|
On Tue, Mar 28, 2006 at 11:34:03PM -0800, Yitzchak Scott-Thoennes wrote:
> That build_requires on Test::More is erroneous, since it is bundled
> in the distribution. It should be removed: (untested)
>
> --- Build.PL.orig 2006-01-20 11:29:18.898665000 -0800
> +++ Build.PL 2006-03-28 23:32:38.812500000 -0800
> @@ -43,9 +43,6 @@
> 'Pod::Readme' => 0.04,
> 'Module::Signature' => 0.21,
> },
> - build_requires => {
> - 'Test::More' => 0,
> - },
> sign => 1,
> create_readme => 1,
And now that I look at it, these definitely should be added:
--- Build.PL.orig 2006-01-20 11:29:18.898665000 -0800
+++ Build.PL 2006-03-28 23:45:28.218750000 -0800
@@ -39,13 +39,12 @@
},
recommends => {
'Archive::Tar' => '1.08',
+ 'ExtUtils::CBuilder' => 0.15,
+ 'ExtUtils::ParseXS' => 1.02,
'ExtUtils::Install' => 0.30,
'Pod::Readme' => 0.04,
'Module::Signature' => 0.21,
},
- build_requires => {
- 'Test::More' => 0,
- },
sign => 1,
create_readme => 1,
|
|
From: Ken W. <ke...@ma...> - 2006-03-29 17:45:39
|
Thanks, I've applied both patches.
-Ken
On Mar 29, 2006, at 1:49 AM, Yitzchak Scott-Thoennes wrote:
> On Tue, Mar 28, 2006 at 11:34:03PM -0800, Yitzchak Scott-Thoennes
> wrote:
>> That build_requires on Test::More is erroneous, since it is bundled
>> in the distribution. It should be removed: (untested)
>>
>> --- Build.PL.orig 2006-01-20 11:29:18.898665000 -0800
>> +++ Build.PL 2006-03-28 23:32:38.812500000 -0800
>> @@ -43,9 +43,6 @@
>> 'Pod::Readme' => 0.04,
>> 'Module::Signature' => 0.21,
>> },
>> - build_requires => {
>> - 'Test::More' => 0,
>> - },
>> sign => 1,
>> create_readme => 1,
>
> And now that I look at it, these definitely should be added:
>
> --- Build.PL.orig 2006-01-20 11:29:18.898665000 -0800
> +++ Build.PL 2006-03-28 23:45:28.218750000 -0800
> @@ -39,13 +39,12 @@
> },
> recommends => {
> 'Archive::Tar' => '1.08',
> + 'ExtUtils::CBuilder' => 0.15,
> + 'ExtUtils::ParseXS' => 1.02,
> 'ExtUtils::Install' => 0.30,
> 'Pod::Readme' => 0.04,
> 'Module::Signature' => 0.21,
> },
> - build_requires => {
> - 'Test::More' => 0,
> - },
> sign => 1,
> create_readme => 1,
>
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking scripting
> language
> that extends applications into web and mobile media. Attend the
> live webcast
> and join the prime developer group breaking into this new coding
> territory!
> http://sel.as-us.falkag.net/sel?
> cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Module-build-general mailing list
> Mod...@li...
> https://lists.sourceforge.net/lists/listinfo/module-build-general
|
|
From: Yitzchak Scott-T. <sth...@ef...> - 2006-03-29 07:39:35
|
On Tue, Mar 28, 2006 at 11:57:24PM -0500, Stephen Adkins wrote: > The two full implementations of YAML in perl are YAML (i.e. YAML.pm) > and YAML::Syck. Neither of them has significant other dependencies. > > YAML - build_requires: Test::Base: 0.49 > requires: perl 5.6.1 YAML bundles Test::Base and shouldn't be listing it in build_requires. I thought Ingy was going to fix that. > YAML::Syck - build requires a C compiler > requires: perl 5.003 > > http://search.cpan.org/src/INGY/YAML-0.58/META.yml > http://search.cpan.org/src/AUTRIJUS/YAML-Syck-0.38/META.yml |
|
From: Chris D. <ch...@cl...> - 2006-03-29 15:12:20
|
On Mar 28, 2006, at 10:57 PM, Stephen Adkins wrote: > The two full implementations of YAML in perl are YAML (i.e. YAML.pm) > and YAML::Syck. Neither of them has significant other dependencies. > > YAML - build_requires: Test::Base: 0.49 > requires: perl 5.6.1 > > YAML::Syck - build requires a C compiler > requires: perl 5.003 > You must be joking! Perl 5.6.1 and a C compiler are VERY significant dependencies. M::B is pure-perl back to 5.005 quite deliberately. Except for Test::More, every one of M::B's required modules has been bundled with Perl itself since 5.005. % corelist Cwd Data::Dumper ExtUtils::Install ExtUtils::Manifest ExtUtils::Mkbootstrap File::Basename File::Compare File::Copy File::Find File::Path File::Spec Getopt::Long IO::File Test::Harness Text::ParseWords Test::More Cwd was first released with perl 5 Data::Dumper was first released with perl 5.005 ExtUtils::Install was first released with perl 5.002 ExtUtils::Manifest was first released with perl 5.001 ExtUtils::Mkbootstrap was first released with perl 5.001 File::Basename was first released with perl 5 File::Compare was first released with perl 5.004 File::Copy was first released with perl 5.002 File::Find was first released with perl 5 File::Path was first released with perl 5.001 File::Spec was first released with perl 5.005 Getopt::Long was first released with perl 5 IO::File was first released with perl 5.00307 Test::Harness was first released with perl 5 Text::ParseWords was first released with perl 5 Test::More was first released with perl 5.007003 > The only reason to have *another* external YAML distribution is to > have one which > has even fewer dependencies (i.e. perl 5.005_03 aka 5.5.3, no C > compiler). Yes, that's it exactly. 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: Ken W. <ke...@ma...> - 2006-03-29 17:43:11
|
On Mar 28, 2006, at 10:57 PM, Stephen Adkins wrote: > Module::Build has the following dependencies. > > requires: > Cwd: 0 > Data::Dumper: 0 > ExtUtils::Install: 0 > ExtUtils::Manifest: 0 > ExtUtils::Mkbootstrap: 0 > File::Basename: 0 > File::Compare: 0 > File::Copy: 0 > File::Find: 0 > File::Path: 0 > File::Spec: 0.82 > Getopt::Long: 0 > IO::File: 0 > Test::Harness: 0 > Text::ParseWords: 0 > perl: 5.005_03 > build_requires: > Test::More: 0 > recommends: > Archive::Tar: 1.08 > ExtUtils::Install: 0.3 > Module::Signature: 0.21 > Pod::Readme: 0.04 I know that list looks long, but so far we only have required dependencies which are part of core for perl 5.6.0, and also possible to install on perl 5.005_03. So it's not as bad as it looks. -Ken |
|
From: Stephen A. <spa...@gm...> - 2006-03-21 04:21:38
|
On 3/20/06, John Peacock <jpe...@ro...> wrote: > Stephen Adkins wrote: > > I have modified a version of Module::Build::Base from Module-Build-0.26= 11 > > to add YAML support sufficient to do everything that Module::Build need= s. > > Excellent! > OK. I have completed the patch for Module::Build::YAML and have attached the patch files rather than inlining them in this message. I created two new files and have attached them also. I do not have write access to the CVS repository so I could not "cvs add" t= hem and include them in the patch/diff file. FILES AFFECTED BY "yaml.diff" (the diff/patch file) MANIFEST - added lib/Module/Build/YAML.pm, t/mbyaml.t lib/Module/Build.pm - change doc to reflect YAML capabilities lib/Module/Build/Base.pm - invoke Module::Build::YAML properly t/metadata.t - remove tests of _yaml_quote_string() NEW FILES lib/Module/Build/YAML.pm - new module. works like YAML.pm for limited cases t/mbyaml.t - new test script NOTE: This patch is against the HEAD, not the 0.2611 branch. Stephen Adkins P.S. Please give me feedback on this patch. I hope to make other contributions in the future, and I hope I'm doing it r= ight. |
|
From: Ken W. <ke...@ma...> - 2006-03-21 04:54:51
|
On Mar 20, 2006, at 10:21 PM, Stephen Adkins wrote: > On 3/20/06, John Peacock <jpe...@ro...> wrote: >> Stephen Adkins wrote: >>> I have modified a version of Module::Build::Base from Module- >>> Build-0.2611 >>> to add YAML support sufficient to do everything that >>> Module::Build needs. >> >> Excellent! >> > > OK. > I have completed the patch for Module::Build::YAML and have > attached the > patch files rather than inlining them in this message. > I created two new files and have attached them also. Looks great, I've committed the patch. I'm thinking we might even want to get rid of our reliance on YAML.pm entirely and use this even when the user *does* have YAML installed. That dependency has been like a monkey around our neck. Or something. > P.S. Please give me feedback on this patch. > I hope to make other contributions in the future, and I hope I'm > doing it right. Yup, this is great. One thing that can make it so you don't have to use multiple attachments is the -N flag to diff, which treats absent files as if they're present but empty. patch will then create the new files. -Ken |
Thanks for helping keep SourceForge clean.
X