On 17 December 2012 01:53, Michael G Schwern <schw...@pobox.com> 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/"
