Re: [Module::Build] You underestimate the problem

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

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