new plumage files
jaleto at gmail.com
Wed Nov 25 18:20:40 UTC 2009
> 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.
Jonathan "Duke" Leto
jonathan at leto.net
More information about the parrot-dev