new plumage files

[Geoffrey Broadwell]

parrot-dev folks: fperrad++ has been giving lots of feedback on Plumage,
and this came up today:

On Mon, 2009-11-23 at 22:56 +0100, François Perrad wrote:
> >> $ ./plumage install lua-batteries
> >>
> >> Installing other projects to satisfy dependencies:
> >>     markdown, mt19937
> >>
> >> Fetching markdown ...
> >
> In fact, there is problem :
> the 'lua' dependency is satisfied by the package 'lua' (the original one),
> so the project Plumage 'lua' (which install parrot-lua) is not fetched.
> 
> There are 2 solutions :
> 1) make a difference between Plumage project and external dependencies
> 2) prefix all project with 'parrot-'

I'm thinking of an option #3, and I'd like some feedback from anyone who
can see any "kills the idea dead" problems with it:

* Dependencies can optionally specify a namespace.  A Rakudo requirement
could be specified as:
  * 'rakudo'         # DWIM -- what happens with current Plumage
  * 'parrot:rakudo'  # only the Parrot project need apply
  * 'lang:perl6'     # a parrot language that provides the 'perl6' HLL
  * 'bin:perl6'      # any binary named 'perl6', not just Rakudo

* Every Plumage project 'foo' provides 'parrot:foo' automatically.

* Any other provides must be specified as 'namespace:name' in the JSON
(as they are now, just with namespaces required).

* Dependencies specified in DWIM form effectively search across all
namespaces known to Plumage, in some hopefully non-braindead order.  For
example, a dependency on 'make' might search the following places:
  * The project list for a project named 'make'
  * The language list for one that provides the 'make' HLL
  * The internal list of binary overrides taken from Parrot config
  * The system PATH for binaries
  * etc.

Anybody see any immediate problems?  (Note that I am not dealing with
versioned dependencies here, that's a whole other ball of wax -- still,
if you see a problem in scaling this scheme up to versioned deps, feel
free to say so.)


-'f