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 [email protected] http://leto.net _______________________________________________ http://lists.parrot.org/mailman/listinfo/parrot-dev
