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

I would suggest that there is scope for both of your suggestions - I particularly like the SHA1 related suggestion since it helps assure the integrity of each installed module.

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.

A user level that continues to overstate my experience :-))
  • 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 21:31 UTC

    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.