|
Re^3: Making the CPAN/GitHub updating process painless
by Your Mother (Archbishop) on Dec 17, 2017 at 05:53 UTC
|
Dist::Zilla is an 800lb gorilla primarily designed for busy CPAN authors of multiple packages. Like Corion, I don't use it. I set it up back in the day but it has, in my estimation, a lopsided cost to benefit ratio for the casual or infrequent author. You'll have to decide if it suits your use case and preferred workflow.
| [reply] |
|
|
There is more than one way to do it. You can release by hand if you want. I don't recommend that because you're unlikely to be able to cross all the Ts and dot all the Is required by meta::cpan in order to properly index your module.
Dist::Zilla automates releasing to CPAN, and is highly configurable. There is more than one way to do it; for example there are half a dozen ways to manage version numbering. This means there is a learning curve, and I doubt that the OP in this thread could accomplish setting it up for himself.
However, as I mentioned in my reply, you can look at the config files for any existing distro and steal what others have used. Many authors publish a bundle of their configs on CPAN, and while that's rather vainglorious in many cases, you can download and study those. My own dist.ini is heavily based on David Golden's author bundle. Also the support group on #distzilla is one of the most active and helpful Perl IRC channels.
Just the fact that a tool is powerful and complex is no reason to discourage its use for the purpose it was designed. I am far from a prolific CPAN author, but I have a few current modules, and much more frequently I contribute to other distros. If I wasn't familiar with dzil I wouldn't be able to collaborate like that.
Moose/Moo, DBIx::Class, Chart::Clicker and even DateTime are other examples of 800-lb gorillas: I don't agree that Perl programmers should be advised against using them because they are complicated. That just leads to dumbing down of code and distros on the CPAN that have no value.
The way forward always starts with a minimal test.
| [reply]
[d/l]
[select] |
|
|
One of the downsides to Dist::Zilla is that it makes it almost impossible to contribute for people without Dist::Zilla installed.
At least the way some people use it to write non-pod documentation and build the test suite, I found it impossible to submit a tested patch agaist the repository and still run the test suite, as both needed Dist::Zilla installed.
Dist::Zilla at least at one time failed its test suite on Windows.
| [reply] |
|
|
|
|
|
|
|
|
|
|
|
My advice was: there is more than one way
to do it and this might suit you, but if you think this one is not a
good match for you, it's not a surprise because it wasn't made for beginners and you are not alone and don't have to feel obligated to force it
because one data point said it was necessary.
I tried using it for awhile and it got in the way and sucked up
time trying to merely replicate a multi-command, one-line alias I've
been using to build and test distributions for 15 years. Maybe
that's a failing on my part and I'd be happier if I'd sunk the time
but I do releases rarely and it's a trivial one command, one upload,
one minute process for me already. It would have cost me many hours to save maybe most of one.
you're unlikely to be able to cross all the Ts and dot all the Is
The CPAN survived a long time and grew to thousands of packages
without Dist::Zilla and I doubt it's even used by a third of authors today so the comment amounts to FUD.
As to 800lb gorillas, I think they all must be weighed, har-har,
carefully. Moo is not really one.
DBIx::Class has no analog other than Rose::DB
and it is an investment in making ongoing workflow easy which is
exactly the use pattern I said Dist::Zilla made sense; I
adore and recommend DBIC often but I have never once said, this is the
only way to do it, and I acknowledge its shortcomings to certain kinds
of power users. I would never recommend Moose at this
point; it does too much that most users never care about or want to
see and there are plenty of much lighter alternatives that work with
uncoupled sidecars like Type::Tiny. DateTime
is fantastic in its scope and attention to detail; its size and
architecture makes it the worst choice in situations where a million
or so dates at a time need to be processed so it's not a gimme any
more than the others. This reminds me of apache as well, which I would
also never recommend today despite it being the unambiguous feature
king. Eschewing apache did not lead to dumbed down webservers but
instead to the lean, lunch annihilating nginx which is now powering a
third of the web and is the only webserver growing in usage.
| [reply] |
|
|
|
|
|
|
| [reply] |
|
|
| [reply] |