Re^2: Per-distro versioning and dependency specification (DRY)

in reply to Re: Per-distro versioning and dependency specification (DRY)
in thread Per-distro versioning and dependency specification

I don't believe that the imported version numbers will be recognized by PAUSE. See the PAUSE documentation, and also this note in Perl::Critic::Policy::Modules::RequireVersionVar:

=head1 TO DO

Add check that C<$VERSION> is independently evaluatable.  In
particular, prohibit this:

    our $VERSION = $Other::Module::VERSION;

This doesn't work because PAUSE and other tools literally copy your
version declaration out of your module and evaluates it in isolation,
at which point there's nothing in C<Other::Module>, and so the
C<$VERSION> is undefined.
[download]

This may cause problems for downstream users who specify per-module dependencies. It's up to you whether you want to support them; some people feel quite strongly about it, such as "Anonymous Monk" above.

Comment on Re^2: Per-distro versioning and dependency specification (DRY) Download Code

Replies are listed 'Best First'.
Re^3: Per-distro versioning and dependency specification (DRY) by tye (Sage) on Jun 07, 2012 at 01:50 UTC
My first reaction was that I didn't think that I cared. PAUSE will get the correct version number for the distribution, which is what matters. 'require' will get the correct version number for what it does. I didn't think of any way that I would care what PAUSE thinks the version number is of a particular package. Then I realized that the problem is probably that trying to set a dependency on " `My::Widget::Flanged => 1.021_031`" would be what could fail. sigh Stupid tools are stupid. If there are indeed "install" tools that are stupid enough to fail for that case, then somebody should consider making them (or PAUSE or the latest "meta.today's-fad-data-encapsulation-format writer") smart enough to use the dist version for the module version when the module version appears to be beyond their ken. Of course, there surely are install tools that are that stupid. There's got to be a dozen install tools by now and most of the ones I've tried I quickly decided to never use again because of how stupid they were. Not that I'm actually convinced that I care. One could still successfully declare a dependence on " `My::Widget::Version => 1.021_031`". Also, having such a distribution as I described probably means that My::Widget would be an even better place to put the version number and depending on " `My::Widget => 1.021_041`" is completely reasonable. What I don't find reasonable is copying and pasting version numbers nor then building annoying tools to assist in that work and all just to allow people to use stupid tools stupidly. Yeah, I'd rather document " `My::Widget::Version => 1.021_041`" being required than resort to copying and pasting version numbers. Though, I find it quite a stretch to imagine myself writing a module distribution where any of this comes up. Given the stupidity of the tools that lead to this dilemma, I might even document that if you want to use My::Widget::Flanged and require at least version V of it, then you have to code that like: `use My::Widget::Version 1.021_031; use My::Widget::Flanged;` [download] - tye	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^3: Per-distro versioning and dependency specification (DRY)
by tye (Sage) on Jun 07, 2012 at 01:50 UTC

My first reaction was that I didn't think that I cared. PAUSE will get the correct version number for the distribution, which is what matters. 'require' will get the correct version number for what it does. I didn't think of any way that I would care what PAUSE thinks the version number is of a particular package.

Then I realized that the problem is probably that trying to set a dependency on " My::Widget::Flanged => 1.021_031" would be what could fail.

*sigh* Stupid tools are stupid. If there are indeed "install" tools that are stupid enough to fail for that case, then somebody should consider making them (or PAUSE or the latest "meta.today's-fad-data-encapsulation-format writer") smart enough to use the dist version for the module version when the module version appears to be beyond their ken. Of course, there surely are install tools that are that stupid. There's got to be a dozen install tools by now and most of the ones I've tried I quickly decided to never use again because of how stupid they were.

Not that I'm actually convinced that I care. One could still successfully declare a dependence on " My::Widget::Version => 1.021_031". Also, having such a distribution as I described probably means that My::Widget would be an even better place to put the version number and depending on " My::Widget => 1.021_041" is completely reasonable.

What I don't find reasonable is copying and pasting version numbers nor then building annoying tools to assist in that work and all just to allow people to use stupid tools stupidly.

Yeah, I'd rather document " My::Widget::Version => 1.021_041" being required than resort to copying and pasting version numbers.

Though, I find it quite a stretch to imagine myself writing a module distribution where any of this comes up. Given the stupidity of the tools that lead to this dilemma, I might even document that if you want to use My::Widget::Flanged and require at least version V of it, then you have to code that like:

use My::Widget::Version 1.021_031;
use My::Widget::Flanged;
[download]

- tye

[reply]
[d/l]
[select]

In Section Meditations