Re: How To Build A Perl Package Database

On 17 December 2012 01:53, Michael G Schwern <[email protected]> wrote:
> On 2012.12.16 11:57 AM, Leon Timmermans wrote:
>> I can agree with all of that. Actually, starting a discussion about
>> this was on my todo-list for the last QA hackathon but I didn't get
>> around to it. Ideally, it should replace not only packlists but also
>> perllocal
>
> I was thinking about what you said about packlists, and I wonder how much
> information one could scrape out of them.  Would it be enough to reconstruct
> at least that a group of files belongs to a release?  That would be enough to
> be able to fully uninstall a requested module.  For example, if the user asks
> to uninstall ExtUtils::MakeMaker the database could have seen that
> ExtUtils/MakeMaker.pm was in a packlist together with ExtUtils/MM_Unix.pm and
> so on and uninstall them.  Probably given their original purpose was to
> provide an uninstaller.
>
> Also what's with this .meta directory I see popping up?  I missed a memo.
>
>
>>> This is all totally doable, and efficient enough, with a small pile of DBM
>>> files and Storable.  Where to put the database is a bit more complicated, see
>>> the list of open problems below.
>>
>> Given that Storable's format isn't forward-compatible, something more
>> stable such as JSON would be more appropriate.
>
> That's a good point about Storable.  JSON requires a dependency.
> ExtUtils::Install could bundle JSON::PP, but it would be simpler to use
> Data::Dumper.  It makes de/serialization faster and simpler.  The main
> disadvantage is its only readable by Perl, but that's ok since this pile of
> DBM files will be opaque to everything but the Perl API.  Too much of a mess
> to contemplate otherwise.

IMO the question is whether you want the data human readable or not.

If you dont care then use Sereal as a replacement for Storable. Same
feature set pretty much except it is faster and produces smaller
output.

Yves

-- 
perl -Mre=debug -e "/just|another|perl|hacker/"