develooper Front page | | Postings from December 2012

Re: How To Build A Perl Package Database

Thread Previous | Thread Next
Tim Bunce
December 17, 2012 19:28
Re: How To Build A Perl Package Database
Message ID:
On Sun, Dec 16, 2012 at 04:53:49PM -0800, Michael G Schwern wrote:
> On 2012.12.16 11:57 AM, Leon Timmermans wrote:
> >> * Where to put the database?  What about non-standard install locations?

> >> Another is to have a separate install database for non-standard install
> >> locations.

A separate install database for each install location seems like the only
workable approach.

> >> This makes sense to me, but it brings in the sticky problem
> >> of having to merge install databases.  Sticky, but still a SMOP.  Once you
> >> have to implement merging anyway, it now makes sense to have an install
> >> database for each install location.  One for core.  One for vendor.  One for
> >> perl.  And one for each custom location.  This has a lot of advantages to
> >> better fit how Perl layers module installs.
> >>
> >>     * allows separation of permissions
> >>     * allows queries of what's installed based on what's in @INC

Perhaps that could be taken one step further: one per installed distribution.

Then, what's kept at each install location is a cached summary of what's
installed below it. One that can be cross-checked against the individual
distribution 'databases' and rebuilt from it.

That seems more robust against various kinds of 'damage'.

> >> That second one is important.  When a normal user queries the database, they
> >> want to get what's installed in the standard library location.  When a
> >> local::lib user queries the database, they want to get what's installed in the
> >> standard library locations AND their own local lib.

I.e., the default view is "what's installed in my @INC".

> > The combination of these is problematic. You might upgrade EU::Install
> > in your local module path, but not have write permissions on the
> > system paths. In practice, we might have to support all our older
> > versions :-|
> Erg, good point.  That very likely scenario is definitely going to require
> some thought.


Here's where "one install database per distribution with a cache
database at the install location" offers another benefit.
The "per distribution install database" can be kept in a very simple
plain text format that targets readability and future-proofing,
while the "cache database at the install location" can target

If an install location has an incompatible version of the db,
the per distribution dbs could be read instead. That's slow but workable
and seems reasonable for that presumably uncommon case.
I can think of a few further options as well.


Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About