Fwd: How To Build A Perl Package Database

---------- Forwarded message ----------
From: Jan Dubois <[email protected]>
Date: Thu, Dec 27, 2012 at 5:40 PM
Subject: Re: How To Build A Perl Package Database
To: Leon Timmermans <[email protected]>


On Thu, Dec 20, 2012 at 2:42 AM, Leon Timmermans <[email protected]> wrote:

> On Mon, Dec 17, 2012 at 9:36 AM, Tim Bunce <[email protected]> wrote:
> > A separate install database for each install location seems like the only
> > workable approach.
>
> One minor complication of that is the strictest sense an "install
> location" isn't all that well defined. Or perhaps I should say every
> dist has 8 install locations with unspecified relationship on the
> filesystem (lib, arch, bin, script, libdoc, bindoc, libhtml, binhtml).
> In practice you may want to use lib *and* arch (they are never used
> simultaneously, but stuff in lib may be shared over different perl
> installations, contrary to arch which should be for one specific
> install).
>

I wonder if it isn't time to deprecate all the complex install combinations
that may have made sense when hard disks was rather limited.

In ActivePerl we enforce a pretty simplified install layout to be able to
create an intuitive package manager:

   - no sharing of directories between different versions
   - every install area has its own bin, etc, lib, and html subdirectories
   - the etc subdirectory records packages installed in that location

Here is how PPM looks (on my Mac, but it is rather similar on Windows or
Unix systems too):
$ ppm area
┌────────┬──────┬────────────────────────────────────────┐
│ name   │ pkgs │ lib                                    │
├────────┼──────┼────────────────────────────────────────┤
│ user*  │   38 │ /Users/jan/Library/ActivePerl-5.16/lib │
│ (site) │  n/a │ /usr/local/ActivePerl-5.16/site/lib    │
│ (perl) │  245 │ /usr/local/ActivePerl-5.16/lib         │
└────────┴──────┴────────────────────────────────────────┘

$ ls /Users/jan/Library/ActivePerl-5.16
bin  etc  html lib

$ ppm query XML
┌──────────────────────┬─────────┬─────────────────────────────────────────────────────────┬──────┐
│ name                 │ version │
abstract                                                │ area │
├──────────────────────┼─────────┼─────────────────────────────────────────────────────────┼──────┤
│ XML-NamespaceSupport │ 1.11    │ a simple generic namespace support
class                │ user │
│ XML-Parser           │ 2.41-r1 │ A perl module for parsing XML
documents                 │ perl │
│ XML-SAX              │ 0.99    │ Simple API for
XML                                      │ user │
│ XML-SAX-Base         │ 1.08    │ Base class for SAX Drivers and
Filters                  │ user │
│ XML-Simple           │ 2.20    │ Easily read/write XML (esp config
files)                │ perl │
│ XML-Stream           │ 1.23    │ Creates an XML Stream connection and
parses return data │ user │
└──────────────────────┴─────────┴─────────────────────────────────────────────────────────┴──────┘
 (6 packages installed matching 'XML')

$ ppm files XML-Stream
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/IO/Select/Win32.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Namespace.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Node.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Parser.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Parser/DTD.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/Tree.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath/Op.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath/Query.pm
/Users/jan/Library/ActivePerl-5.16/lib/XML/Stream/XPath/Value.pm
/Users/jan/Library/ActivePerl-5.16/lib/auto/XML/Stream/.packlist

$ ppm remove XML-NamespaceSupport
XML-NamespaceSupport: required by XML-SAX
ppm remove failed: No packages uninstalled

Having a separate perl/bin and perl/site/bin and perl/vendor/bin is
somewhat inconvenient for adding things to the $PATH, but it makes it
possible to install an updated core package into the site directory, and
later uninstall it without breaking the original core version. We don't use
perl/vendor but instead merge all pre-installed packages into the core
directories to keep $PATH a little shorter.

Anyways, I just wanted to say that without putting some restrictions on how
modules (and corresponding scripts) can be installed, creating a package
manager would seem to get even more complex than ExtUtils::Makemaker... :)

Cheers,
-Jan