(Adam raises doubts if his mails come through to the list. Because I
think they don't, I cite him in full length)

>>>>> On Mon, 02 Oct 2006 17:22:10 +1000, Adam Kennedy <[EMAIL PROTECTED]> said:

  > (Andreas J. Koenig) wrote:
 >>>>>>> On Mon, 02 Oct 2006 12:05:56 +1000, Adam Kennedy <[EMAIL PROTECTED]> 
 >>>>>>> said:
 >> 
 >> > I'm of the opinion tha as soon as we say...
 >> 
 >> > use Module::Build;
 >> 
 >> > ... then we've already lost. We're mixing the two different functions
 >> > together in the same process.
 >> 
 >> It's a noble goal to think in purist terms but it's also a matter of
 >> available alternatives. As soon as we had a well respected and widely
 >> adopted META.yml we had to recognize that it isn't autoritative. But
 >> you cannot have both worlds: either there is an authoritative source
 >> that tells me prerequisites or I have to ask the tool that the
 >> developers use to build their package.

  > Oh but you can have both worlds :)

  > We have currently META.yml, which is only advisory but suitably
  > describes all the metadata that a CPAN might like to know in a way
  > that's easy to get at.

  > Then we run the installer/configure script (Makefile|Build).PL which
  > will then determine similar metadata for the specific system and
  > circumstances.

  > You can see this as "localizing" the metadata (i.e. the information in
  > META.yml).

  > Now, in the case of ExtUtils::MakeMaker, you don't go into that
  > process, you just read the localized metadata from a file it writes
  > out. In that case if I'm remembering correclty, it's the actual
  > Makefile where it writes out a section you can read.

You're right, that was a surprisingly well working hack. Makefile.PL
wrote a *comment* into the Makefile that could be parsed out again.

  > It seems fairly logical to me that this process "run installer, read
  > deps" should work pretty well, because it isolates your CPAN client
  > code from the installer code, which theoretically could be hacked up
  > all to hell with customisations.

Agreed.

  > One thing I had blindly assumed at one point, because I thought it was
  > so obvious, that one ExtUtils::MakeMaker and Module::Build are both
  > capable of generating META.yml files, that when you run the
  > installers, they would just overwrite the uploaded META.yml with a
  > replacement "localized" for the current plaform.

  > So instead of reading META.yml before the installer/configure to
  > determine the deps, you just read if AFTER the installer/configure
  > run, and you get the dependcies that are specific to the current
  > platform, and recurse on that basis.

  > That avoids the messyness of loading Module::Build into memory, and
  > would serve as an interesting replacement for reading our of the
  > Makefile (if you added support to ExtUtils::MakeMaker).

No objections. Provided that that META.yml is good enough. So this
will need another round of development.

  > Now, I can certainly see where you might potentially get into some
  > trouble with different authors on different platforms overwriting each
  > others META.yml in a repository.

  > But having the installer "localize" the META.yml would seem to me to
  > be a valid option.

Good.

  > Of course, if for various authoring or back-compatibility reasons you
  > don't want to overwrite the existing META.yml, perhaps then you add a
  > feature where after running the installer, you look for a
  > seperately-named local file, say for the sake of example, META.local
  > or LOCAL.yml or LOCALMETA.yml or what have you.

  > Then you just

  > 1. Read META.yml, look for dynamic_config: 0. If so recurse to deps
  > 2. Run Makefile.PL or Build.PL
  > 3. Look for META.local. If so recurse to deps
  > 4. Otherwise, use Makefile scanning or whatever you do now

  > Thoughts?

I like it. Curious if Ken will like it as well. Maybe there is already
a way to play it without changes to Module::Build?

  > Adam K

  > P.S. Are my emails actually making it to the mailing lists and my
  > client is just not showing them, or have I been banned or blocked from
  > the mailing lists some how...

I did not see your response to Dave Rolsky either, so I assume you're
blocked.

  > Or more simply, can anyone see this on the lists?


-- 
andreas

Reply via email to