Re^4: Using a Single Point of Truth for $VERSION in a distribution?

I have now had time to read the Dist::Zilla tutorial and after checking its dependencies, I believe that I will have to pass on dzil for now.

To use a term I have seen elsewhere in the Monastery, my conclusion was ETOOMUCHMAGIC. Dist::Zilla seems to be the type of tool that I have had problems with in the past, being elegant, complex, powerful, — and fragile. It will work and it will work very well and the details of making it work will be forgotten. Then a future upgrade will break something. I have had to handle systems like that at $WORK in the past and I prefer simpler answers for my hobbies, but that is my preference and you are of course free to enjoy the power while it works. :-)

Comment on Re^4: Using a Single Point of Truth for $VERSION in a distribution? Select or Download Code

Replies are listed 'Best First'.
Re^5: Using a Single Point of Truth for $VERSION in a distribution? by NERDVANA (Priest) on Apr 20, 2020 at 17:29 UTC
Dist::Zilla is complicated and has a learning curve, but actually once you get it configured the way you like you can forget most of the details and just copy the dist.ini from one project to the next, making a few changes as needed. Language::FormulaEngine dist.ini Geo::SpatialDB dist.ini Elf::Writer dist.ini (notice how in the source for FormulaEngine I just add a `#VERSION` comment and `dzil build` inserts the incremented version from the last git tag.) I totally agree with the sentiment you are expressing about not wanting to waste tooling time on a personal project, but this one really will pay for itself if you release a few modules. I wish Dist::Zilla was not written as a giant pile of heavyweight Moose roles, but the external design is absolutely correct (running "dzil test", "dzil build", "dzil release" and so on) and I have been able to make all the customizations I've needed even for some wild makefile requirements: Data::TableReader dist.ini weaver.ini (example adding "Contributors" POD section auto-generated from Git) VideoLAN::LibVLC dist.ini Makefile.header (example of exotic c-library detection using MakeMaker::Awesome plugin) OpenGL::Sandbox dist.ini (example using Inline::Module plugin to distribute a module using Inline::C as a standard XS module not depending on Inline)	[reply] [d/l] [select]

Replies are listed 'Best First'.

Re^5: Using a Single Point of Truth for $VERSION in a distribution?
by NERDVANA (Priest) on Apr 20, 2020 at 17:29 UTC

(notice how in the source for FormulaEngine I just add a #VERSION comment and dzil build inserts the incremented version from the last git tag.)

I totally agree with the sentiment you are expressing about not wanting to waste tooling time on a personal project, but this one really will pay for itself if you release a few modules.

I wish Dist::Zilla was not written as a giant pile of heavyweight Moose roles, but the external design is absolutely correct (running "dzil test", "dzil build", "dzil release" and so on) and I have been able to make all the customizations I've needed even for some wild makefile requirements:

Data::TableReader dist.ini weaver.ini (example adding "Contributors" POD section auto-generated from Git)
VideoLAN::LibVLC dist.ini Makefile.header (example of exotic c-library detection using MakeMaker::Awesome plugin)
OpenGL::Sandbox dist.ini (example using Inline::Module plugin to distribute a module using Inline::C as a standard XS module not depending on Inline)

[reply]
[d/l]
[select]