module-build-general

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

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

I have a problem with META.yml generation and platform dependencies.

It looks to me like CPAN is using META.yml to resolve dependencies
instead of letting Build.PL or Makefile.PL handle it. But there doesnt
appear to be a way to express that in a  METAL.yml. So when i do a
build/make dist I end up with a METAL.yml that specifies a win32
specific dependency, and when people on other OSes try to build they
try to grab a win32 specifc module.

Before I hack whatever it is that generates the META.yml to handle
this im wondering if there is anything better to be done? What happens
if a package doesnt contain a META.yml?

I also think it raises an interesting question. How to express dynamic
dependencies in a form like META.yml? It seems to me only in a limited
fashion.

cheers,
Yves

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

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

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

Hi Yves,

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

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

  -Ken


On Apr 12, 2006, at 12:36 PM, demerphq wrote:

> I have a problem with META.yml generation and platform dependencies.
>
> It looks to me like CPAN is using META.yml to resolve dependencies
> instead of letting Build.PL or Makefile.PL handle it. But there doesnt
> appear to be a way to express that in a  METAL.yml. So when i do a
> build/make dist I end up with a METAL.yml that specifies a win32
> specific dependency, and when people on other OSes try to build they
> try to grab a win32 specifc module.
>
> Before I hack whatever it is that generates the META.yml to handle
> this im wondering if there is anything better to be done? What happens
> if a package doesnt contain a META.yml?
>
> I also think it raises an interesting question. How to express dynamic
> dependencies in a form like META.yml? It seems to me only in a limited
> fashion.

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

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

On 4/13/06, Ken Williams <ke...@ma...> wrote:
> Hi Yves,
>
> This is a known shortcoming of CPAN's approach to dependency
> detection.  There's no solution inside the META.yml itself, though in
> some distant future version we'd like to expand the little language
> that describes dependencies so it would indeed be capable of
> expressing platform-specific dependencies.
>
> In the meantime, I'm not sure what to suggest - if you omit the
> META.yml I assume CPAN would try another method, but I'm not sure.
> It's also possible that if you put dynamic_config =3D> 1 in the
> META.yml it could try another method, but I'm certainly not sure
> about that either. :-/

Seems like if the META.yml creation occured on the installers machine
instead of on the distributors machine the problem would go away, and
allow inifinte flexibility.

So for the time being it looks like I have to hand hack my MakeMaker
or something. Hmm.

Yves


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

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

[Chris D. <ch...@cl...>]

On Apr 13, 2006, at 1:40 AM, demerphq wrote:

> Seems like if the META.yml creation occured on the installers machine
> instead of on the distributors machine the problem would go away, and
> allow inifinte flexibility.

Heh, that scenario would remove the need for a META.yml completely,  
wouldn't it?

Unfortunately, that doesn't solve the reason for META.yml's  
existence: to allow people to inspect module metadata without needing  
to execute untrusted code.

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/)

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

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

On 4/13/06, Chris Dolan <ch...@cl...> wrote:
> On Apr 13, 2006, at 1:40 AM, demerphq wrote:
>
> > Seems like if the META.yml creation occured on the installers machine
> > instead of on the distributors machine the problem would go away, and
> > allow inifinte flexibility.
>
> Heh, that scenario would remove the need for a META.yml completely,
> wouldn't it?

Depends what you consider the objective of having a META.yml

If its to provide a clean abstraction layer for installation agents
like CPAN to process then no.

> Unfortunately, that doesn't solve the reason for META.yml's
> existence: to allow people to inspect module metadata without needing
> to execute untrusted code.

If the objective is to avoid the execution of untrusted code then no
you would be right.

But im not sure that that is the objective. Im not saying it isnt,
but, it seems to me that a client like CPAN is going to execute the
Makefile.PL or Build.PL regardless, so it doesnt seem to me like its a
big win in terms of security.

I mean, it seems to me the difference is purely one of whether the
client executes the build script _before_ or _after_ reading the
META.yml.  Given that i see no change in the security profile.

Yves

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

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

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

On Apr 13, 2006, at 10:25 AM, Chris Dolan wrote:

> On Apr 13, 2006, at 1:40 AM, demerphq wrote:
>
>> Seems like if the META.yml creation occured on the installers machine
>> instead of on the distributors machine the problem would go away, and
>> allow inifinte flexibility.
>
> Heh, that scenario would remove the need for a META.yml completely,  
> wouldn't it?
>
> Unfortunately, that doesn't solve the reason for META.yml's  
> existence: to allow people to inspect module metadata without  
> needing to execute untrusted code.

The reason for having the META.yml isn't really security, but more  
convenience.  Version numbers, author names, module names, abstracts,  
etc. are spread out all over the tarball usually, but the META.yml  
just puts them in one place.

It can be a security issue for the PAUSE site or search.cpan.org or  
whatever, which might receive a poison tarball, but for the average  
user they've opened themselves wide open anyway.

  -Ken

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

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

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

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

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

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

==> TODO


-- 
andreas

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

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

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

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

Cheers.
yves


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

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

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

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

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

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


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


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

-- 
andreas

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

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

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

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

s/content/config/g;

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

  -Ken

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

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

On Apr 13, 2006, at 1:40 AM, demerphq wrote:

> Seems like if the META.yml creation occured on the installers machine
> instead of on the distributors machine the problem would go away, and
> allow inifinte flexibility.
>
> So for the time being it looks like I have to hand hack my MakeMaker
> or something. Hmm.

That won't work.  CPAN is looking at the META.yml file before running  
*anything*, including your MakeMaker code.

Also, there's already a file called _blib/prereqs that's written  
while running the Build.PL script, and will contain any dynamically  
specified prereqs.

I did bring up this issue with Andreas when he was proposing the  
META.yml-reading behavior for CPAN, but he figured he's cross that  
bridge when we came to it.  I think we've come to it?

  -Ken

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

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

On 4/13/06, Ken Williams <ke...@ma...> wrote:
>
> On Apr 13, 2006, at 1:40 AM, demerphq wrote:
>
> > Seems like if the META.yml creation occured on the installers machine
> > instead of on the distributors machine the problem would go away, and
> > allow inifinte flexibility.
> >
> > So for the time being it looks like I have to hand hack my MakeMaker
> > or something. Hmm.
>
> That won't work.  CPAN is looking at the META.yml file before running
> *anything*, including your MakeMaker code.

Actually I meant my ExtUtils-MakeMaker installation. Ill have to hand
hack it to prevent the  reference to Win32API::File being included in
the dist.

> Also, there's already a file called _blib/prereqs that's written
> while running the Build.PL script, and will contain any dynamically
> specified prereqs.
>
> I did bring up this issue with Andreas when he was proposing the
> META.yml-reading behavior for CPAN, but he figured he's cross that
> bridge when we came to it.  I think we've come to it?

Yep, seems like.

Cheers,
Yves


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

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

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

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

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

		- Tyler