No need to comment more. Really.
Any patch, or bug report, or anything at all really, is preferred to not hearing anything at all, so if you don't want to build the full distribution in order to send me a failing test or a patch or whatever, that's fine. However I *do* include a CONTRIBUTING file in all my repositories -- tailored specifically to that dist even -- that explains how to work on the code without installing/using Dist::Zilla. https://metacpan.org/source/ETHER/Dist-Zilla-PluginBundle-Author-ETHER-0.047/share/CONTRIBUTING
Any test that needs a dzil build first in order to run is clearly labelled as such, with a skip_all in place if the full build is missing. Distributions that do not put something like this in place are a little more hostile to contributors, so they should address this. But hating on the tool itself is like hating on steelworkers because guns and swords exist.
And passive-aggressive whining on the internet just makes you look bad. Be a part of the solution, not the problem! http://shadow.cat/blog/matt-s-trout/the-power-of-asking/
]]>Faaaaaaaaaaaaaaaaaaaaakkkkkkkkk. THE BUG IS BACK. Previewing my comment expires my session!!!!!!!!!!!!!!!!!
Try # 3 (or else) (the first was expiry after a few days of non-use, which is fine):
Thanx for your CONTRIBUTING doc. I've saved that URL. It should be a primary Dist::Zilla document if you ask me.
One look at Dist::Zilla and my gut reaction was ... Not for me! But of course anyone else is free to adopt it. For those who think it improved their productivity - congratulations, you've very lucky.
I have adopted 15 modules, but when considering others - Neil's List - I always pass on ones which use Dist::Zilla.
As for my own modules, I always now start a new project by copying a pre-existing one and then editg the Build.PL and Makefile.PL files. It suits me, and it has to suit me. YMMV.
Cheers
Ron
I don't want any build infrastructure. All I want is to *install* the package
Which one is it, now?
Or actually, you’re right – on such modules, cp -R
will do the job without any build infrastructure. It’s a free country.
Waiting for release on cpan.org is so oldschool.
No further questions, your honour.
]]>https://metacpan.org/pod/Dist::Milla#WHY
Dependencies are available in cpanfile and you can run `cpanm --installdeps .` to get them installed.
I'm not going to comment on other things.
]]>I have experienced many of the same frustrations with Dist::Zilla as you. Some Dist::Zilla advocates -- including contributors to this thread -- have responded to me just as they did to you in this thread. And I have not been persuaded.
Nonetheless, the tone of your original post is, in my opinion, unhelpful and counterproductive. In the open source world -- indeed, in the online world in general -- people evaluate you not just on the technical content of your posts but on the personal character you project through your posts. And once you post something, it's up there forever. Please bear this in mind when you post here and on other Perl sites in the future.
Thank you very much.
Jim Keenan
https://github.com/plack/Plack/pull/442
https://github.com/plack/Plack/blob/master/dist.ini
But cool site, nevertheless.
IIRC, a web-based REPL for Perl 6 was once online. The Pugs-based one as well as Rakudo/Parrot one.
]]>Oh I won’t call it well written, believe me. :-) I’ve tried to patch it at times, succeeded with trivial stuff outside the interpreter guts, and I’ve read others’ patches. I don’t have a firm grasp of it but I do have a sense of what it’s like to work with. It’s not as terrible as its reputation, and there are some really clever bits (that I mostly wish weren’t necessary…), but it’s no kind of beauty. Kinda like Perl-the-language (but with its coherence more corrupted by time), come to think of it.
]]>If you, as a user, need to install a git snapshot of a project hosted
at GitHub, you can use https://undzilit4.me/ for that and you don't
need to bother about all the plugins. It's not equivalent to "git
clone", but you get what you want.
btw, when packaging .deb files, Debian tools expect tarballs too. And if you try to build .deb from git clone, debian workflow looks broken.
Yes, that was annoying for those who author Perl modules with
Dist::Zilla which are primarily shipped as .deb, e.g. in corporate
environments.
But there's a solution for that now: dh-dist-zilla, a debhelper plugin
which allows you to build a .deb from Dist::Zilla based distribution
without having Makefile.PL or Build.PL -- they will be generated
because "dzil build" is run to generate the Makefile.PL later used by
dh_auto_configure and friends.
See https://github.com/elmar/dh-dist-zilla and
https://packages.debian.org/dh-dist-zilla