in reply to <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support - what NOW makes sense.

I see your point with SHA1 hashes, and it does seem to work well for git.

But remember that git keeps a database that lets you map that SHA1 hash to a date, author, log message and diff - and the other way round. If you don't have such a database, all you'll get on a SHA1 mismatch is just that - a message "hash verification failed", no more informations.

It also implies that you can't require a minimum version of a module, just one specific version.

(I do agree on your point of having just version number per distribution - I do that already, and it works fine for me; other solutions are svn $Id$ tags that automatically get expanded into revision numbers).

So in summary I think that it might be worth pondering such an idea if you redo the complete module loading and distribution system, but I don't think it's feasible to plug onto the existing system.

Note that Rakudo, a Perl 6 implementation, is now sufficiently advanced that people write modules for it, and want to distribute them. If you're into actually building something, they'll happily accept anything that actually works, and that tracks versions and dependencies.

(The emphasis is on building stuff - we have enough people that are happy to discuss it, but discussions don't deploy code. Programs do.)

  • Comment on Re: <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support - what NOW makes sense.
  • Download Code

Replies are listed 'Best First'.
Re^2: <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support - what NOW makes sense.
by otto (Beadle) on Apr 21, 2009 at 20:37 UTC

    Thanks for the feedback

    My ref's to git was simply as a jumping ground, not specific applications.

    ...git keeps a database that lets you map that SHA1 hash to a date, author, log message and diff

    Again analogy. Remember that 02packages.details.txt.gz as dist'd by cpan contains the following: module, version, dist. So each module has a version or undef. So there really is a "current" concept of mapping a hash->module->dist as "current". Furthermore a concept of top-level module can provide a concept of version, which applies to the whole dist.

    It also implies that you can't require a minimum version of a module, just one specific version.

    Not true. Again the top-level module is the "version" for the whole dist, and hence all modules part of the dist. So you could spec a min or max version for a "module" which would imply the top-level module of the dist, and you get the min version required result.

    ...but I don't think it's feasible to plug onto the existing system

    Actually I'm working on a module in which I hope to incorporate some of these ideas

    ...discussions don't deploy code. Programs do.

    It is the automation of this that I'm suggesting. Shipit is facilitating a better solution, but that solution pushes a version in each file. I question whether this is needed by posing the question of what ::VERSION is really used for.

[reply]
[d/l]
      Again analogy. Remember that 02packages.details.txt.gz as dist'd by cpan contains the following: module, version, dist. So each module has a version or undef. So there really is a "current" concept of mapping a hash->module->dist as "current".

      Sure, but it's CPAN.pm that reads 02packages.details.txt.gz, not perl. Maybe I didn't fully understood what you want to do, but if you want be able to write things like 

      use My::Module 'sha1:DEADBEEF... or above';

      [download]

      and have perl verify that checksum, then perl needs to have access to that database, not only cpan. And it would need to store all hashes of all previous versions of all installed modules - which seems a bit like overkill.

      Actually I'm working on a module in which I hope to incorporate some of these ideas

      Ah, maybe I jumped to conclusions while reading the "perl core support" from the subject line.

[reply]
[d/l]

In Section Meditations