Piotr Roszatycki

Yep. That's why I use the Git::CommitBuild plugin, to give you both https://github.com/dakkar/Net-Stomp-MooseHelpers/tree/v2.1-dzilla (what I write) and https://github.com/dakkar/Net-Stomp-MooseHelpers/tree/v2.1 (what you can use without dzil).

This way, anyone can send me patches for whichever version they're most confortable with, and I can easily check bug reports against the code they're actually using (without having to rebuild it)

Yep.

That's why I stopped contributing to padre after two days wasting my time to distzilla caused problems. I just wanted to debug some broken plugins, which was not possible by the usual build test, or direct execution of t/some.t in the source tree. The reason was, that version numbers were checked, but they were not in the source, but set by dzil (via PPI!).

Second, in nearly all cases where I installed distzilla (on a clean and well installed current debian) one of the 300 dependencies of distzilla did not install without errors.

I think dzil is useful in some cases. Personally I have stopped using it, but I see why others do. I really really agree about plugin bundles. There have been times when i have intended to submit a patch and then decided not to for that reason.

Git repositories of distzilla based packages are not usable for rpm packaging. I often just add rpm spec file to repository and build rpm-package from git clone. To build such rpm-package i'll need to pollute my custom rpm-repository with hundreds PluginBundle's (and similar) modules just to be able to run dzil successfully.

Hey, guys!

Distzilla is just different. You need _tarball_ to install/run/rpm-pack the module. Git copy is not suitable for this. Git copy is only for authoring (yes, and to submit patch).

btw, when packaging .deb files, Debian tools expect tarballs too. And if you try to build .deb from git clone, debian workflow looks broken.

Why do you need a Makefile.PL or Build.PL in a repo? If it's a pure Perl module you can do everything you need to simply by running prove.

For my XS modules I always do add a minimal Makefile.PL or Build.PL to the repo for the sake of potential contributors.

More often than not you can hack on a module without Dist::Zilla just fine.

Tests can usually be run simply as `prove -lr t/`, so usually you can actually hack on the code and test the results without touching dzil.

If that doesn't work, any author I've ever discussed this with would accept a working patch against CPAN tarballs just as well; in most workflows those can be applied to the dzilified git repository as-is anyway.

> Fortunately usually I can prepare tiny stub with Makefile.PL:

I have plenty of dists are more complicated than that…

Al Newkirk set up this section in my dist.ini that solves this problem for me by copying the Makefile.PL and Build.PL from the build directory into the dist directory, which is then committed.

[Run::BeforeBuild]
run = rm -f LICENSE
run = rm -f Makefile.PL
run = rm -f Build.PL
run = rm -f README
run = rm -f README.mkdn

[Run::AfterBuild]

run = cp %d/LICENSE ./

run = cp %d/Makefile.PL ./

run = cp %d/Build.PL ./

run = cp %d/README ./

run = cp %d/README.mkdn ./

It does have the drawback of making the tree dirty during a build when the content of these files change, requiring some additional steps during the release, but the benefit to contributors is worth it.

For pure-Perl modules I consider it a problem if any build infrastructure is necessary to use the module (e.g. during working on it).

It’s Perl. Just add the relevant lib to @INC.

If that doesn’t work (as in the Padre case complained above, I surmise), then someone made a bad choice somewhere.

A source repository is not the same thing than the delivered package

No need to comment more. Really.

I'm a heavy Dist::Zilla user. My output in the last year has gone up tenfold because of this, so saying "you suck because you use this tool" strikes me as quite rude and antisocial.

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/

@Jean-Damien Durand, +1

Hi Ether

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

Because nobody mentioned, i need to point out that Milla (based on Dist::Zilla) is written specifically to solve that problem.

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.

Piotr,

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

Piotr: you just contributed to a project using Dist::Zilla (via Milla).

https://github.com/plack/Plack/pull/442
https://github.com/plack/Plack/blob/master/dist.ini

I have to echo what Jim Keenan said about the tone of this post. It really is about _how you say it_. This stuff hangs around not only on disk but in human memory. I've seen people who are technically proficient get passed over for job interviews because they don't play well with others online. You're not just putting a message out to the world in general, but to people who could possibly be future co-workers, employers, managers etc. We all have bad days, but "there's more than one way to say it", so it's not a bad strategy to choose your words and your tone wisely.