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 _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
