Before joining in the previous CPAN threads, here are some personal wish
lists regarding what the perl6 version of CPAN should do. But in order
to get some distance from CPAN, I want to call it the Module Library
system. Some of the debate threads impact on the internal software
environment, and here I think the internal and external environments
must be designed in harmony.
A library paradigm is different from an archive paradigm, although a
library is a form of archive. However, a library is a single place to go
to obtain information. It is set up to enhance searching and finding. An
archive is a place where things are stored; the users of an archive know
what and where they are storing. Hence the difference between an archive
and a library is a set of assumptions about what a user knows. Archives
are essential for large libraries (often called stacks), but there must
be standardised metadata about what is in each archive for it to be
useful for a library.
So my wish list. I would like:
1) a single place to go for modules that will help me solve programming
problems;
2) a variety of ways to look through modules and the information on them
- reviews, documentation, dependencies - so that I can choose between
them and know what a choice entails;
3) a variety of classifications of modules and module contents that can
lead me to modules which may achieve what I want but are named in a
manner I did not expect, or contain functionality I could use in another
context;
4) a means to extract from the library the module(s) I want, (better
still only the parts of the module) and all their dependencies;
5) the ability to access existing CPAN perl software.
Extending the library paradigm, there are generalist libraries, which
only contain commonly requested books, and specialist libraries and also
libraries in other languages. However, good libraries share systems for
requesting books from other libraries, even if they are not stored
locally. The difference between libraries then boils down to the
metadata available to the user, eg., more accessible user catalogs,
librarians who know about subjects and can point to related books, etc.
The library paradigm breaks down somewhat for software because there is
an intimate link between my environment and the software I choose.
Hence, it is important to consider the internal environment (my
computer) as well as the external environment (the module libraries).
Not only is there the problem of different operating systems (*ix,
windows*, mac, etc), there is also the possibility of outdated software
installed, eg., different versions of languages, such as perl 5.8, perl
5.10.
Within my environment, there are multiple possible locations for
different aspects of software, eg. binaries, configuration data (which
can be global to all users and local for a single user), documentation,
data, results. In a corporate environment, these locations may exist
across a network. For example, documentation may be on a server,
binaries and local configuration data on the local computer, results
posted to a web site, input data taken from a database.
My wish list for the internal environment; I would like:
1) a single system to manage all my software modules;
2) a method to see where different aspects of software are located, and
to change them;
3) an ability to manage in parallel different dependency hierarchies
(such as might result from a need to use modules from different
generations (eg. perl 5.8 and 5.10).
4) a comprehensive method to determine what my local environment is, so
that I can see whether it matches the environment required by software
that I want to download, and if not, what I need in addition to be able
to run the software.
Some commentary on the above:
I use the CPAN archive, CPANPLUS, and synaptic (a GUI frontend to the
apt tools) for perl since I use Ubuntu/Gnome. In some cases I have to
load binaries using synaptic because I cant get the sources to compile
properly from CPAN. I do not have the time or inclination to discover
why. The result is a mishmash of dependencies. Moreover, I cannot get
updated software without breaking something. This occurred when the one
Ubuntu generation was distributed with perl5.8 even though perl5.10 was
out, and I really wanted to use some of the new software.
The result was that I had both 5.8 and 5.10 modules. Although most
things worked, perldoc wasnt recognised by some Configure scripts. I am
not interested now in discovering the reason. I use this simply as an
example about how multiple distribution channels that make different
assumptions can lead to problems. But because there is no single method
for monitoring the perl environment, it is difficult to solve some of
the problems.
The current setup works extremely well, except when it doesnt. My
difficulty is finding out how to solve the problems that occur. So I
think there should be a system that
