new plumage files

Jonathan Leto jaleto at gmail.com
Wed Nov 25 18:20:40 UTC 2009


Howdy,

[snip]
> 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.)
>
>

I like this idea and don't see any immediate problems if we want to go
down the "versioned deps" path later on.

+1

Duke



-- 
Jonathan "Duke" Leto
jonathan at leto.net
http://leto.net


More information about the parrot-dev mailing list