Beefy Boxes and Bandwidth Generously Provided by pair Networks
No such thing as a small change
 
PerlMonks  

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

by tye (Cardinal)
on Jun 06, 2012 at 17:31 UTC ( #974792=note: print w/ replies, xml ) Need Help??


in reply to Per-distro versioning and dependency specification

Why is everybody copying version numbers all over the place in their distributions?

First, I agree that it presents problems to have more than one version number associated with a CPAN module distribution (since only one version number per distribution matters when uploading and sorting at CPAN and installing doesn't really support anything beyond "pick one version of the whole dist to install and use").

Second, I have written several module distributions that include more than one package and have never felt the need to expose version numbers except via one package per distribution. And I have never (in any module) done anything with version numbers beyond the default "let the user request 'at least version V'". Version numbers should clearly monotonically increase. So of far more importance to me than most possible aspects of version numbers is the clarity in sorting order. Most attempts to assign "meaning" to parts of version numbers usually just end up causing pain, IME.

So, in the theoretical case of me writing a module that includes multiple packages where there isn't one "main" package that always gets used and so is the only place that needs to support "require at least version V", here is how I would implement that (because it means that there is exactly one place where I track the current version number):

Makefile.PL: ... VERSION_FROM => 'lib/My/Widget/Version.pm', ... lib/My/Widget/Version.pm: package My::Widget::Version; require Exporter; our @EXPORT_OK = '$VERSION'; *import = \&Exporter::import; our $VERSION = 1.011_021; lib/My/Widget/Flanged.pm: package My::Widget::Flanged; use My::Widget::Version '$VERSION'; ...

Nothing at all complicated about that. And if you don't want to pull in Exporter, then you have to have two simple lines in each "versioned" package instead of just the one.

Are there any ways in which that trivial solution is not better than any module that does work to copy-and-paste a version string into multiple files or that just checks that you did the copy-and-paste correctly?

- tye        


Comment on Re: Per-distro versioning and dependency specification (DRY)
Download Code
Re^2: Per-distro versioning and dependency specification (DRY)
by creamygoodness (Curate) on Jun 07, 2012 at 00:26 UTC

    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.

    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.

      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;

      - tye        

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: note [id://974792]
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others browsing the Monastery: (4)
As of 2014-09-21 17:35 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    How do you remember the number of days in each month?











    Results (173 votes), past polls