Rob Kinyon wrote:

On 5/28/05, Rob Kinyon <[EMAIL PROTECTED]> wrote:
(This thread is referencing

I'd like to start writing the Module::Build/ExtUtils::MakeMaker for
Pugs. One of the first things that was mentioned was that the syntax
for use needs to support specifying the exact version or range of
versions you want to have. There has also been mention of the fact
that module installation needs to tag the author, as well as other

Would someone please mind listing all the functionality desired for
module installation as seen from "use"?

Note: I've read S11. I was asking more for the backstory.

1) Does this mean that there can be two different Dog-1.2.1, one by
cpan:JRANDOM and another by cpan:KRANDOM?


2) Is @INC still searched in order, providing the first one that
matches the full specification?

No, it searches for the _best_ match. Best is defined by first filtering based on given Name/Version/URI conditions given in the use statement. Then it picks the highest version number. If there are still multiple candidates around, I believe Larry settled on throwing an error, rather than create a tiebreaker that authors would jockey for on CPAN.

Some related questions:
1) Is it possible for "use" to expose the functionality it uses to
find the right module to other modules? For example, the module
installer I want to write would have to have that logic and I'd rather
not duplicate it.

Likely yes, but I think that might be a p6c question.

2) That functionality I referred to - theorbtwo on Perlmonks asked for
the ability to provide mixins that would direct how some of the
functionality worked. Would this be possible?

"All's fair if you predeclare". At a minimum you could redefine the part of the grammar that parses and evaluates the "use" statements. Higher levels of exposure have not been discussed, AFAIK. Proposals welcome.

3) The P6 version of XS - will it be handled at the VM level or the
Perl level? I'm assuming the VM level, which then leads to:

Definitely VM.

4) "use" and non-Perl code - One of the touted things about using
Parrot is that a P6 program will be able to access code in any
language that targets Parrot. How on earth will that work?
5) Mixed-language distributions - how should a P6 distro builder
handle that? How should a P6 distro installer handle that? How should
C6PAN handle that?
6) Is there a useful distinction to be made between modules/classes
and distributions? I think there is when discussing uninstalling. I
install Dog and it provides Dog::Retriever. If I uninstall Dog, it
should also uninstall Dog::Retriever.
7) This leads to the thought that a distribution should have a name
separate from any of the components within it. I expect that, like URI
or Template Toolkit, there will be a component in the distribution
that has the same name as the distro, but that will be custom and not

I don't think any of this has been deeply considered yet.

Here are my musings on the topic after roughly 45 seconds of thought:

Rather than have a concept of a "perl 6" libpath, only have a "parrot" libpath. Then, whenever a module is searched for, it matches against anything in the parrot repository, which would contain all parrot bytecode, from various source languages. Therefore, installing mixed language packages is simply a matter of shipping pre-compiled versions of the library out, and there may be a split between bytecode/doc distros, and full source distros.

I have no thoughts on how to handle the (un)installation of collections.

-- Rod Adams

Reply via email to