Geoffrey Broadwell wrote:
2. Use libraries provided by other HLLs.
Ever since the major HLLs were split from Parrot, option 2 has become
weaker, in the sense that no HLL can *count* on another HLL being
available. Thus HLL and HLL module implementers are more likely to
reimplement than tell their users "Want to use my spiffy new Cardinal
module? First install Rakudo and these Rakudo modules ...."
Some libraries can be precompiled to PBC and shipped as Parrot modules
that way. This is substantially preferable to reimplementing the whole
library.
> The following are some tests that I would use to help make
> the decision:
I mostly agree with your criteria, but you missed a big one: The
long-term investment of developer resources in *maintaining* the modules
once we include them.
The module set shipped in Parrot core should be small, with extensions
shipped separately. Parrot is not a language like Python, Ruby, etc.
It's a compiler toolchain like GCC.
1. True core
Just what is needed to get read access to the module repo. Parrot
release management owns these (they are considered part of Parrot in
every sense, including deprecation cycles), and they should be truly a
minimal set.
Agreed except for the "module repo" part. There are so many free ways of
distributing software these days (SourceForge, GitHub, Google Code,
Debian, Cygwin, Active State, etc), there's very little value in
creating a CPAN-like module repository.
Having Parrot modules in every major code repository works for us, far
more than being silo'd into a dedicated Parrot module repo. It's all
about visibility, and increasing the chances of a random person
stumbling across module X that solves their problem, and just happens to
require Parrot.
2. Basic batteries
The stuff everyone has hashed to death, agree on, and (like DBDI) form a
common layer through which other things are easy to plug in. The Parrot
and HLL teams work together to decide what goes into this set, with a
general preference for less rather than more. We may want to have a
separate "basic batteries release manager" who takes care of making
these releases (perhaps on the same day as Parrot Core, perhaps a day or
two later), thus taking stress and politics off the Parrot Core release
manager.
Aside from DBDI, I'm not sure what would go here, and even DBDI should
likely have more independence than this would allow.
3. Power packs
What we currently think are the most common modules people would want
for a particular market segment. For example, there could be a "Power
Pack for Scientists" and a "Power Pack for Hackers". Anyone should be
able to create and manage power packs, and it is expected that the
market place of ideas will do its magic -- for example, someone may
decide to make a "Power Pack for Bioinformatics" that has more focus and
depth than the general scientific pack. These are explicitly NOT
managed by the Parrot team; we merely support the tools necessary to
make them easy to install. I personally think we should try to create a
culture among the power pack owners to deprecate and clean regularly,
but as pmichaud pointed out, there is likely a market for power packs
(especially in the business spaces) that make stability and long-term
support the primary goal.
This idea I really like. And it's not just individual developers likely
to create these bundles, we can expect commercial bundles too. Also
virtual packages in distributions, to bundle up a group of module packages.
And, don't forget that language implementations are really just modules
too. So, we'll likely see the Rakudo Pack, Python Pack, etc.
4. Go use the module repo
If you need anything not in a power pack, just use the module repo
directly; the tools to use it are after all part of Parrot Core.
All modules should be installable from source, using some simple, common
build/installation framework (make, autoconf, etc...), but we're not
going to dictate one that everyone has to use. For now I suspect most
modules will copy Parrot's makefile generation technique, since we
provide some tools to make that relatively easy.
If a developer expects their module to be commonly used, it should be
packaged for our major target distributions and operating systems (we
can provide tools for that too).
Allison
_______________________________________________
http://lists.parrot.org/mailman/listinfo/parrot-dev
