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.)

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.

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.

You could make a module part of your distribution whose job is only to hold the distribution version number.

package Your::Dist::Version;

# note no strict

$VERSION = 1.23;

sub import {
    my $pkg = caller;
    ${ "$pkg\::VERSION" } = $VERSION;
}

1;
[download]

Then use Your::Dist::Version from every module in the distribution. Everything that does has the One True Version inserted into its namespace. You can change it in one place and keep other info in that one file as convenient.

Another way is to make the top-level module more akin to a base of the whole dist, which in some manners it is. Then others inherit the version. Class::MOP::Object provides dump for everything ...

At issue is to examine and dissect what really is the use of ::VERSION for each of the concepts of file, module, package, and distribution. These are all very different, but often are used interchangeably due to some of the syntactic sugar applied to them. Dealing with versioning means you really need to carefully examine the distinctions

Then use Your::Dist::Version from every module in the distribution. Everything that does has the One True Version inserted into its namespace.

But it won't work.

The CPAN indexer searches for lines in modules that seems to set the VERSION number, extracts that line, and executes it. Just that line. Nothing more. Any clever tricks you'd like to use will work at run time (for instance, if someone does use Module VERSION;), but the important part, the CPAN indexer, won't be able to find the version number.

Sorry if that might seem ignorant, but why is that a problem? Can't the CPAN indexer simply take the version from the META.yaml and take that as a default version?

Then all you have to do is to make sure that the meta data and Your::Dest::Version agree.

From a $Pkg::VERSION POV, IMO (& I speak as a CM practitioner of many years standing), there is no one standard approach since the degree to which version control is required will, in almost every case, be required to be flexible enough to handle situations varying from top-level module only, down to every module.

Furthermore, I'm interested in how your proposal would handle the situation whereby 2 otherwise separate modules are installed over the same directory space e.g. Some::Class::Frob & Some::Class::Nicate, each being a top-level module in it's own right, but neither is top-level when installed maybe an argument for version id on an individual basis.

Multiple cases:

Case Simple:

Distribution containing:

Some/Class/Frob.pm (which contains package Some::Class::Frob)

and nothing else.
and
Distribution containing:

Some/Class/Nicate.pm (which contains package Some::Class::Nicate)

and nothing else.

Well this is the simplist, each Frob.pm and Nicate.pm contain a VERSION for each of their dists and a HASH::SHA1 value for each. No issues.

Case Typical:

Distribution containing:

Some/Class/Frob.pm (which contains package Some::Class::Frob)

and nothing else.
and


Distribution containing:

Some/Class/Nicate.pm (which contains package Some::Class::Nicate)
Some/Class/Nicate/nsp1.pm (which contains package Some::Class::Nicate::nsp1)
Some/Class/Nicate/nsp2.pm (which contains package Some::Class::Nicate::nsp2)
Some/Class/Nicate/nsp2/nsp21.pm (which contains package Some::Class::Nicate::nsp2::nsp21)
Some/Class/Nicate/nsp2/nsp22.pm (which contains package Some::Class::Nicate::nsp2::nsp21)

Frob.pm contains VERSION for its distribution and a HASH::SHA1 value for itself.

Nicate.pm contains a VERSION for its distribution and a HASH::SHA1 value for itself.

nsp1.pm contains a VERSION which is a sub fetching the version of Nicate.pm and contains a HASH::SHA1 value for itself.

similar for nsp2.pm, nsp21.pm, nsp22.pm.

Case Harder - not simple module to file to package mapping.

Distribution containing:

Some/Class/Frob.pm (which contains package Some::Class::Frob)
Some/Class/Frob/nsp1.pm (which contains package Some::Class::Frob::nsp1)
Some/Class/Frob/nsp2.pm (which contains package Some::Class::Frob::nsp2)

Distribution containing:

Some/Class/Nicate.pm (which contains package Some::Class::Nicate)
Some/Class/Nicate/nsp1.pm (which contains package Some::Class::Nicate::nsp1)
Some/Class/Nicate/nsp2.pm (which contains package Some::Class::Nicate::nsp2 and contains package Some::Class::Frob::nsp1)

Ugh, so dist Some-Class-Nicate has a file that contains multiple packages, one of which populates its module package space (i.e. module name mapped to file on file system contains package same as module name) and it contains package Some::Class::Frob::nsp1.

So what do you want for versioning? ::VERSION is what is defined within a package or forced into a package name space.

I contend that you would NOT place a ::VERSION in the package namespace for Some::Class::Frob::nsp1 as defined in Some::Class::Nicate::nsp2. You would have a ::VERSION in Some::Class::Nicate::nsp2 which is a sub fetching the version from the top-level module of dist for Some::Class::Nicate and you would have a HASH::SHA1 for the Some/Class/Nicate/nsp2.pm. Module requirement would be for Some::Class::Nicate::nsp2::VERSION (a sub). That would be the case even if the only change was in Some::Class::Frob::nsp1 as found in Some::Class::Nicate::nsp2 because the only way to get the change is to require Some::Class::Nicate::nsp2. You can not partially require a module. (Well I lie, you can with BEGIN & co).

Hopefully that addresses what you were asking.

What if this became a part of perl core?

For all the suggestions I've heard the past years to change the CPAN VERSION handling, yours is the most insane. By a long shot.

Suppose modules used git SHA1 numbers as versions. Now I want to install Module X. Module X needs module Y, and at least version 81AC89FE38.... I have version DA21348FF0... installed. Quick, do I need to update module Y to be able to use module X or not?

Exactly the point. The concept of a version number and a file identification should be separate concepts.

As analogy git has separated the concept of a file name and the file contents. The file contents is a blob which has an id. The id is then related to a name in the tree object. They are two separate concepts. The concept of version number, more like a git tag, identifies a group of items, a hash uniquely identifies the contents of something, in the case we are discussing, files as related to modules and packages in perl.

...yours is the most insane. By a long shot.

Thank you - either i'm insane or cutting new trails :)