lucy-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Marvin Humphrey <>
Subject Re: [lucy-dev] Re: Failed: PAUSE indexer report KARMAN/Lucy-0.3.0.tar.gz
Date Thu, 01 Mar 2012 02:17:45 GMT
On Wed, Feb 15, 2012 at 09:17:57AM -0800, David E. Wheeler wrote:
> You built the distribution with Module::Build version 0.3603, which sets
> versions in the "provides" section to `undef` if there is no version.
> I built 0.2.2 with Module::Build version 0.38, which sets missing versions
> in the "provides" section to 0. From the CPAN indexer’s point of view, 0 !=
> undef.

Hmm.  That's unfortunate.

> I argue, however, that *all* Lucy modules should have explicit versions.
> Why? Let’s say that I have a module that depends on
> Lucy::Analysis::Analyzer. So I declare in my Build.PL:
>     requires => {
>         'Lucy::Analysis::Analyzer' => 0,
>     }
> So far so good, right? But let’s say that I later realize that I need a new
> feature in 0.3.0. Si I change it to:
>         'Lucy::Analysis::Analyzer' => '0.3.0',
> If someone tries to build, it will fail, because there is no such version.
> In fact, CPAN cannot tell the difference between the
> Lucy::Analysis::Analyzer in 0.3.0 and the Lucy::Analysis::Analyzer in 0.2.2
> or any other release. Because we did not give it a version number. Since the
> best practice is for developers to declare requirements on modules they
> actually `use`, and one may not actually `use Lucy;`, folks may not then
> require a specific version of Lucy, but rather of a module that Lucy
> packages.
> So, IME, it is best for every Perl module in a distribution to have its own
> version. This version does not have to change with each release if its
> contents have not changed, but I tend to find that a bit complicated (since
> other modules it depends on may have changed, and those changes might have
> side-effects on my module). So better, IME, is to have the same version in
> every single module in a distribution.


I really wish that Perl/CPAN version numbers were only associated with
distributions, rather than classes/Perl-packages/modules/scripts/whatever.

I also wish that distribution version numbers were tracked entirely separately
from executable code.  Honestly, deriving a version number by eval'ing a
snippet which has been heuristically extracted from Perl module code is a
dreadful hack.  

And of course I wish that the CPAN toolchain's version number handling was
not so fragile.  I'm leery of changing anything at all about our version
numbers because the system has a tendency to break in all kinds of strange

Here's a minimalist alternative proposal:

  * Don't insert per-package version numbers.
  * Verify Module::Build 0.38 or above when running "./Build dist".

Going that route won't add support for the case of requiring a specific
version of individual classes like Lucy::Analysis::Analyzer, but at least it
won't break anything and we can stop burning developer time.

> There are two ways to do this. One is to have this line in every .pm file:
>     our $VERSION = '0.003001';
> Then, before a release (or just after a release, depending on your
> preferences), you would change it every file. I do that with something like:
>     ack -laiQ 0.003000 | xargs perl -i -pe "s{\QVERSION = '0.003001'}{VERSION = '0.003001}g"
> Some might find it a bit annoying, but it’s probably the safest way to
> manage Perl module versions.

We don't take chances with updating version numbers.  There's a script we run:


I'm worried about adding all these new version numbers everywhere -- it's a
massive violation of DRY.  I predict that we will screw up and miss some in
the future.

Probably we should add a test to ACTION_dist in Lucy::Build that parses the
META.yml and loops over every package under "provides" to verify that it has
the right version number.

> The second way to do it is lazier: Just put this line in every Perl module
> in a distribution:
>     require Lucy; our $VERSION = eval $Lucy::VERSION;
> And yes, it has to be on one line so that Module::Build will parse out the
> one line and eval it. I think this would be safe, though I don’t know if you
> want to load in every file.
> Anyway, best practice is to have an explicit version in every module and to
> make sure it’s properly set for every release.

See my reply to Peter for why this technique poses problems for us.

Marvin Humphrey

View raw message