in reply to Re: Using a Single Point of Truth for $VERSION in a distribution?
in thread Using a Single Point of Truth for $VERSION in a distribution?

The testsuite verifies an import error for version 9999, but this discussion has given me the idea of keeping the typeglob aliases in the repository while changing them to literals just before rolling up a release tarball.

Thanks to all for the help.

  • Comment on Re^2: Using a Single Point of Truth for $VERSION in a distribution?

Replies are listed 'Best First'.
Re^3: Using a Single Point of Truth for $VERSION in a distribution?
by 1nickt (Canon) on Apr 20, 2020 at 13:25 UTC

    So, in the end you decided to reimplement Dist::Zilla? ;-)

    If you set up a dist.ini specifying only Dist::Zilla::Plugin::PkgVersion you would have the same thing, but without having to deal with typeglobs in your module sources.

    Or, you could use Dist::Zilla::Plugin::OurPkgVersion which changes: 

    package My::Module;
# VERSION

    [download]
    to: 
    package My::Module;
our $VERSION = '0.01'; # VERSION

    [download]
    with a dist.ini like: 
    ...
version = 0.01;
[OurPkgVersion]

    [download]
    That is the first versioning system I used when I began with Dist::Zilla. You have to manually set the version number in your dist.ini before you build. I now use the plugins I shared earlier in this thread, so once I start a project and specify the initial version, I never have to touch the version number myself again.

    (... and of course dzil will also run the tests, build the Makefile and meta files, roll the tarball and push to CPAN ... and commit and push the changes to your Git repo, if you configure it to.)

    Of course you could build a tool to do this (will it return the source files to their "typeglob" state after rolling the tarball?). But why would you? I don't see that there's any less magic in that approach than in using the framework that many of the leading CPAN authors trust with their contributions.

    Hope this helps!


    The way forward always starts with a minimal test.
[reply]
[d/l]
[select]
      So, in the end you decided to reimplement Dist::Zilla? ;-)

      Yes, for the one, specific, narrow function I need and without using Moose. In fact, I am planning to write a pair of shell scripts because I do not want to automate uploading to CPAN. One pre-release script and one post-release script. I have been burned by "Sorceror's Apprentice" mistakes too many times in the past.

      without having to deal with typeglobs in your module sources

      The typeglobs in the module sources are actually trivial to handle; in effect, they are simply a fancier way to write "# VERSION" that perl can also understand.

      (will it return the source files to their "typeglob" state after rolling the tarball?)

      Yes, using git reset — I already store the release tarball in the repository on a tagged branch, then reset the working tree so that continued development does not accumulate tags on master over time.

      I don't see that there's any less magic in that approach than in using the framework that many of the leading CPAN authors trust with their contributions.

      I see it as less magic because it does less — I have no desire to autogenerate a boilerplate README or any of the other fancy options Dist::Zilla offers. The rest of that sentence is a classic bandwagon fallacy.

[reply]
[d/l]
[select]
        > git reset

        Do you really need to change the source code in the repository? Can't you run the change in the distribution directory only? (I don't know the answer).

        map{substr$_->[0],$_->[1]||0,1}[\*||{},3],[[]],[ref qr-1,-,-1],[{}],[sub{}^*ARGV,3]
[reply]
[d/l]

In Section Seekers of Perl Wisdom