Re^2: <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support

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.

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

Replies are listed 'Best First'.
Re^3: <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support - what NOW makes sense. by moritz (Cardinal) on Apr 21, 2009 at 20:51 UTC
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]

Replies are listed 'Best First'.

Re^3: <pkg>::VERSION, git, hashes, shipit, Class::MOP, Moose, perl core support - what NOW makes sense.
by moritz (Cardinal) on Apr 21, 2009 at 20:51 UTC

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]