new plumage files
geoff at broadwell.org
Mon Nov 23 23:44:33 UTC 2009
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
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.)
More information about the parrot-dev