Mailing List Archive

Dist::Zilla considered harmful for Bleads Break CPAN reports.
I keep encountering BBC tickets for modules which have code hosted on
github, but which have no actual way to build the code in the repo
because they use Dist::Zilla and expect Dist::Zilla to generate it all
pre-release. This is fine for joe-random hacker worker on their own or
in a small team with agreed build conventions and requirements. It is
a total nightmare when you are someone like me who really has no
interest in Dist::Zilla and who doesn't want to have to learn it just
to fix your module when it breaks due to a core change.

The way Dist::Zilla works makes it very difficult and time consuming
to deal with modules that use it. It means I have to build and install
a latest perl, then install Dist::Zilla and all its dependencies
(takes about an hour or more?), and then i have to go read the docs on
Dist::Zilla on how to get it to do anything useful. Basically it makes
fixing bugs a serious burden instead of being a pleasurable session of
debugging and puzzle solving. I mean a Dist::Zilla based repo
typically doesn't even include a file that says what to do with the
repo to get it to build. I know I am supposed to run some "dzil"
command, but I tend to have to reread the docs to remember what the
heck that command is. It just seems like Dist::Zilla is *designed* to
be hostile towards third party builders who aren't used to the
toolchain.

I really am reaching the point where I say "I don't do BBC support for
modules hosted on GitHUb that use Dist::Zilla." Module::Build is bad
enough, but Dist::Zilla is much much worse. I don't want to be this
person, if I break your code by a core change I really strongly
believe I should be involved in fixing it. But when people build their
modules using Dist::Zilla that support becomes much more costly to
provide, and frankly the frustration to reward seems wildly out of
sync with each other, especially the reward goes to someone else, but
I get to keep all the frustration.

I don't know if anyone cares about this, but I feel sure that
Dist::Zilla could be changed to be much more friendly to people who
will be building other peoples repos. One thing that comes to mind is
maybe someone who knows Dist::Zilla can write a tool for core which
can "de-fang the zilla" in a github repo by downloading the latest
version of the release from CPAN and then inserting the build files
into the repo that contains the code. (Waves hands.) Or whatever, I
don't care really, I just don't think I should have to wait an hour
for cpanm to install half of CPAN to even be able to compile the code,

Anyway, thoughts and help would be appreciated here.

cheers,
Yves
cc'ed Andreas on this as he maybe has some thoughts on this and he
tends to be the person I get my BBC reports from.


--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
demerphq <demerphq@gmail.com> wrote:
:I keep encountering BBC tickets for modules which have code hosted on
:github, but which have no actual way to build the code in the repo
:because they use Dist::Zilla and expect Dist::Zilla to generate it all
:pre-release. [...]
:I mean a Dist::Zilla based repo
:typically doesn't even include a file that says what to do with the
:repo to get it to build.

+1, I have had this experience when trying to provide bugfixes to modules,
but I never got as far as you have.

For my cases sometimes I ended up offering a patch without ever having
built the module (which feels wrong), sometimes I just gave up - I was not
prepared to attempt to install something that boasts in its docs that it
feels free to make "ludicrous demands in terms of prerequisites".

Hugo
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
Hi there,

On Wed, 18 Jan 2023, demerphq wrote:

> I keep encountering BBC tickets for modules which have code hosted on
> github, but which have no actual way to build the code in the repo
> because they use Dist::Zilla and expect Dist::Zilla ...

our %anathema =
{
'Yves' => 'Dist::Zilla',
'Ged' => 'github',
}

--

73,
Ged.
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, 18 Jan 2023 at 14:33, G.W. Haywood via perl5-porters
<perl5-porters@perl.org> wrote:
>
> Hi there,
>
> On Wed, 18 Jan 2023, demerphq wrote:
>
> > I keep encountering BBC tickets for modules which have code hosted on
> > github, but which have no actual way to build the code in the repo
> > because they use Dist::Zilla and expect Dist::Zilla ...
>
> our %anathema =
> {
> 'Yves' => 'Dist::Zilla',
> 'Ged' => 'github',
> }

I dont consider Dist::Zilla anathema. I just consider it needlessly
harmful to the ecosystem. It seems like it could be changed to be less
so. I dunno. I just dont want to spend an hour before I can even get
to start debugging the core issue I am trying to address.

cheers,
Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, 18 Jan 2023 13:56:35 +0100
demerphq <demerphq@gmail.com> wrote:

> I keep encountering BBC tickets for modules which have code hosted on
> github, but which have no actual way to build the code in the repo
> because they use Dist::Zilla and expect Dist::Zilla to generate it all
> pre-release.
...
> Anyway, thoughts and help would be appreciated here.

+1 to all that.

I mentioned on IRC but again here for posterity: Ages ago I wrote a
tool for handling this; App::sourcepan

https://metacpan.org/dist/App-sourcepan/view/bin/sourcepan

With it you can easily create yourself a local git checkout (or bzr or
whatever other VCS tooling you prefer) initialised with the upstream
CPAN module source:

$ sourcepan --git Some::Module

From there you can easily build it because you're working with the
built CPAN version and not the plain upstream in whatever odd format
they're using. Once you've done your hackery you can create a patch
using your preferred local tooling and send that upstream to the
maintainer, whereon it becomes their problem to deal with it if it
happens not to apply to their upstream source. (Though likely if it's
just small changes to .pm files it should be fine).

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, Jan 18, 2023 at 8:33 AM <hv@crypt.org> wrote:
>
> demerphq <demerphq@gmail.com> wrote:
> :I keep encountering BBC tickets for modules which have code hosted on
> :github, but which have no actual way to build the code in the repo
> :because they use Dist::Zilla and expect Dist::Zilla to generate it all
> :pre-release. [...]
> :I mean a Dist::Zilla based repo
> :typically doesn't even include a file that says what to do with the
> :repo to get it to build.
>
> +1, I have had this experience when trying to provide bugfixes to modules,
> but I never got as far as you have.
>
> For my cases sometimes I ended up offering a patch without ever having
> built the module (which feels wrong), sometimes I just gave up - I was not
> prepared to attempt to install something that boasts in its docs that it
> feels free to make "ludicrous demands in terms of prerequisites".

I don't understand this at all. If this was a BBC report for a module
that doesn't link to the git repo, wouldn't you download the tarball
from cpan, attempt a fix there, generate a patch from a diff and send
it?

This is no different - if you don't want to fight with Dist::Zilla no
one is forcing it.

-- Matthew Horsfall (alh)
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, 18 Jan 2023 09:35:36 -0500, "Matthew Horsfall (alh)" <wolfsage@gmail.com> wrote:

> On Wed, Jan 18, 2023 at 8:33 AM <hv@crypt.org> wrote:
> >
> > demerphq <demerphq@gmail.com> wrote:
> > :I keep encountering BBC tickets for modules which have code hosted on
> > :github, but which have no actual way to build the code in the repo
> > :because they use Dist::Zilla and expect Dist::Zilla to generate it all
> > :pre-release. [...]
> > :I mean a Dist::Zilla based repo
> > :typically doesn't even include a file that says what to do with the
> > :repo to get it to build.
> >
> > +1, I have had this experience when trying to provide bugfixes to modules,
> > but I never got as far as you have.
> >
> > For my cases sometimes I ended up offering a patch without ever having
> > built the module (which feels wrong), sometimes I just gave up - I was not
> > prepared to attempt to install something that boasts in its docs that it
> > feels free to make "ludicrous demands in terms of prerequisites".
>
> I don't understand this at all. If this was a BBC report for a module
> that doesn't link to the git repo, wouldn't you download the tarball
> from cpan, attempt a fix there, generate a patch from a diff and send
> it?
>
> This is no different - if you don't want to fight with Dist::Zilla no
> one is forcing it.

The net result is that no patch is created *at all*, because

$ wget https://some/site/release.tgz
$ tar xzf release.tar.gz
$ cd release
$ perl Makefile.PL
- shit, no Makefile.PL
$ perl Build.PL
- shit that is missing too
$ less INSTALL
- no INSTALL file
$ less README
- no ref to build procedure

give up. bye

replace wget with any other means of downloading the tarball, as
replacing .tar.gz with .tgz, .tbz, or .txz or whatever.

having no "normal" way to build a dist using the two by default
supported tools is a threshold that hinders people like me to create a
patch in the first place, as a patch should be tested, and not being
able to build and test a release withou having to update or install 1700
modules to fulfill the prereqs of Dist::Zilla is not an option.

That is how I *feel* it

> -- Matthew Horsfall (alh)


--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, 18 Jan 2023 at 15:35, Matthew Horsfall (alh) <wolfsage@gmail.com> wrote:
>
> On Wed, Jan 18, 2023 at 8:33 AM <hv@crypt.org> wrote:
> >
> > demerphq <demerphq@gmail.com> wrote:
> > :I keep encountering BBC tickets for modules which have code hosted on
> > :github, but which have no actual way to build the code in the repo
> > :because they use Dist::Zilla and expect Dist::Zilla to generate it all
> > :pre-release. [...]
> > :I mean a Dist::Zilla based repo
> > :typically doesn't even include a file that says what to do with the
> > :repo to get it to build.
> >
> > +1, I have had this experience when trying to provide bugfixes to modules,
> > but I never got as far as you have.
> >
> > For my cases sometimes I ended up offering a patch without ever having
> > built the module (which feels wrong), sometimes I just gave up - I was not
> > prepared to attempt to install something that boasts in its docs that it
> > feels free to make "ludicrous demands in terms of prerequisites".
>
> I don't understand this at all. If this was a BBC report for a module
> that doesn't link to the git repo, wouldn't you download the tarball
> from cpan, attempt a fix there, generate a patch from a diff and send
> it?

For me personally, generally no. If something doesn't have a github
repo I can clone I just file a RT ticket and leave it to them. Ill
eyeball the code on cpan and write a description of what I think needs
to be done.

I'd say of the BBC tickets I look at for core fixes, maybe 1 in 15
(likely less) has no repo link on metacpan. To me when a module author
does not include a repo link it is a sign that a module is not well
maintained and likely I will be wasting my time writing a patch
anyway. Either the person is someone like LeoNerd who likes to do
things their own way, and won't apply your patch verbatim anyway, or
it is abandonware and the author wont respond anyway. If the person
responds to the RT I do my best to work with them as well as I can,
but i wont bend over backwards if the other side is making life
difficult.

FWIW, I wrote a patch once for a module based on what was on CPAN. It
was an entirely wasted effort, when I finally found their repo they
had loads of unpublished changes, and my patch wouldn't apply. So
since then I have been pretty wary of making patches against the
latest release.

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, Jan 18, 2023 at 9:54 AM <perl5@tux.freedom.nl> wrote:
> The net result is that no patch is created *at all*, because
>
> $ wget https://some/site/release.tgz

Where did you get this tarball from? The one from CPAN (this is a
Blead Breaks CPAN report) would include a Makefile.PL or a Build.PL.

Also there's `cpanm --look Some::Module` and then you're set to
build/test/patch.

-- Matthew Horsfall (alh)
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, Jan 18, 2023, at 07:56, demerphq wrote:
> I keep encountering BBC tickets for modules which have code hosted on
> github, but which have no actual way to build the code in the repo
> because they use Dist::Zilla and expect Dist::Zilla to generate it all
> pre-release.

Out of curiosity, did you try "prove -lr t" (for example) to just run the tests from the repo?

(I'm not sure what the importance of "build" specifically is.)

--
rjbs
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, 18 Jan 2023 15:53:56 +0100
perl5@tux.freedom.nl wrote:

> $ perl Makefile.PL
> - shit, no Makefile.PL
> $ perl Build.PL
> - shit that is missing too

If it's a CPAN tarball it really must have at least one of Makefile.PL
or Build.PL, otherwise CPAN.pm (or any other local CPAN client) would
be unable to install it.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, Jan 18, 2023 at 3:59 PM demerphq <demerphq@gmail.com> wrote:

> If the person
> responds to the RT I do my best to work with them as well as I can,
> but i wont bend over backwards if the other side is making life
> difficult.


Agreed. I once had a module suggestion rejected because I accidentally
misspelled the module owner's name. They pretty much shut me down, even
after I apologized. After internal discussion with the client's team, the
consensus was "fork them" (you can read that as you will). "Plays well with
others" is important. Anyone who doesn't play well with others should
usually be ignored. That's how we can build a better community.

That being said, many other languages have complicated, and often
contradictory, build systems. How do they deal with this?

--
Curtis "Ovid" Poe
--
CTO, All Around the World
World-class software development and consulting
https://allaroundtheworld.fr/
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, 18 Jan 2023 10:00:29 -0500, "Matthew Horsfall (alh)" <wolfsage@gmail.com> wrote:

> On Wed, Jan 18, 2023 at 9:54 AM <perl5@tux.freedom.nl> wrote:
> > The net result is that no patch is created *at all*, because
> >
> > $ wget https://some/site/release.tgz
>
> Where did you get this tarball from? The one from CPAN (this is a
> Blead Breaks CPAN report) would include a Makefile.PL or a Build.PL.

It was a generic example. Probably - like what Yves referred too -
a git clone or a tar provided by an author.

> Also there's `cpanm --look Some::Module` and then you're set to
> build/test/patch.

Ah, completely forgot about cpanm. I am an old-school EU::MM user,
so I only use "cpan" (= a truckload of distroprefs)

> -- Matthew Horsfall (alh)

--
H.Merijn Brand https://tux.nl Perl Monger http://amsterdam.pm.org/
using perl5.00307 .. 5.37 porting perl5 on HP-UX, AIX, and Linux
https://tux.nl/email.html http://qa.perl.org https://www.test-smoke.org
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, 18 Jan 2023 at 16:04, Ricardo Signes <perl.p5p@rjbs.manxome.org> wrote:
>
> On Wed, Jan 18, 2023, at 07:56, demerphq wrote:
>
> I keep encountering BBC tickets for modules which have code hosted on
> github, but which have no actual way to build the code in the repo
> because they use Dist::Zilla and expect Dist::Zilla to generate it all
> pre-release.
>
>
> Out of curiosity, did you try "prove -lr t" (for example) to just run the tests from the repo?
>
> (I'm not sure what the importance of "build" specifically is.)

Unfortunately every time this has come up it has involved XS code, so
running prove directly isn't/wasn't an option.

cheers,
Yves

--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
perl5@tux.freedom.nl writes:

> On Wed, 18 Jan 2023 10:00:29 -0500, "Matthew Horsfall (alh)" <wolfsage@gmail.com> wrote:
>
>> Also there's `cpanm --look Some::Module` and then you're set to
>> build/test/patch.
>
> Ah, completely forgot about cpanm. I am an old-school EU::MM user,
> so I only use "cpan" (= a truckload of distroprefs)

`cpan` also has a `look` command.

- ilmari
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, 18 Jan 2023 at 16:50, Dagfinn Ilmari Mannsåker
<ilmari@ilmari.org> wrote:
>
> perl5@tux.freedom.nl writes:
>
> > On Wed, 18 Jan 2023 10:00:29 -0500, "Matthew Horsfall (alh)" <wolfsage@gmail.com> wrote:
> >
> >> Also there's `cpanm --look Some::Module` and then you're set to
> >> build/test/patch.
> >
> > Ah, completely forgot about cpanm. I am an old-school EU::MM user,
> > so I only use "cpan" (= a truckload of distroprefs)
>
> `cpan` also has a `look` command.

I have noticed lately that cpan and cpanm aren't /that/ different
anymore. When i forget the 'm' it still works. :-)

Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, Jan 18, 2023 at 7:57 AM demerphq <demerphq@gmail.com> wrote:

> I keep encountering BBC tickets for modules which have code hosted on
> github, but which have no actual way to build the code in the repo
> because they use Dist::Zilla and expect Dist::Zilla to generate it all
> pre-release. This is fine for joe-random hacker worker on their own or
> in a small team with agreed build conventions and requirements. It is
> a total nightmare when you are someone like me who really has no
> interest in Dist::Zilla and who doesn't want to have to learn it just
> to fix your module when it breaks due to a core change.
>
> The way Dist::Zilla works makes it very difficult and time consuming
> to deal with modules that use it. It means I have to build and install
> a latest perl, then install Dist::Zilla and all its dependencies
> (takes about an hour or more?), and then i have to go read the docs on
> Dist::Zilla on how to get it to do anything useful. Basically it makes
> fixing bugs a serious burden instead of being a pleasurable session of
> debugging and puzzle solving. I mean a Dist::Zilla based repo
> typically doesn't even include a file that says what to do with the
> repo to get it to build. I know I am supposed to run some "dzil"
> command, but I tend to have to reread the docs to remember what the
> heck that command is. It just seems like Dist::Zilla is *designed* to
> be hostile towards third party builders who aren't used to the
> toolchain.
>
> I really am reaching the point where I say "I don't do BBC support for
> modules hosted on GitHUb that use Dist::Zilla." Module::Build is bad
> enough, but Dist::Zilla is much much worse. I don't want to be this
> person, if I break your code by a core change I really strongly
> believe I should be involved in fixing it. But when people build their
> modules using Dist::Zilla that support becomes much more costly to
> provide, and frankly the frustration to reward seems wildly out of
> sync with each other, especially the reward goes to someone else, but
> I get to keep all the frustration.
>
> I don't know if anyone cares about this, but I feel sure that
> Dist::Zilla could be changed to be much more friendly to people who
> will be building other peoples repos. One thing that comes to mind is
> maybe someone who knows Dist::Zilla can write a tool for core which
> can "de-fang the zilla" in a github repo by downloading the latest
> version of the release from CPAN and then inserting the build files
> into the repo that contains the code. (Waves hands.) Or whatever, I
> don't care really, I just don't think I should have to wait an hour
> for cpanm to install half of CPAN to even be able to compile the code,
>
> Anyway, thoughts and help would be appreciated here.
>

This (among other reasons) is why my preferred usage of dzil has always
been to regenerate the Makefile.PL and META.json into the repo.
Unfortunately this is up to each author to decide to implement (unless they
use my Starter::Git bundle, in which case they can simply use the
regenerate option)

-Dan
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, Jan 18, 2023 at 12:42 PM Dan Book <grinnz@gmail.com> wrote:

> On Wed, Jan 18, 2023 at 7:57 AM demerphq <demerphq@gmail.com> wrote:
>
>> I keep encountering BBC tickets for modules which have code hosted on
>> github, but which have no actual way to build the code in the repo
>> because they use Dist::Zilla and expect Dist::Zilla to generate it all
>> pre-release. This is fine for joe-random hacker worker on their own or
>> in a small team with agreed build conventions and requirements. It is
>> a total nightmare when you are someone like me who really has no
>> interest in Dist::Zilla and who doesn't want to have to learn it just
>> to fix your module when it breaks due to a core change.
>>
>> The way Dist::Zilla works makes it very difficult and time consuming
>> to deal with modules that use it. It means I have to build and install
>> a latest perl, then install Dist::Zilla and all its dependencies
>> (takes about an hour or more?), and then i have to go read the docs on
>> Dist::Zilla on how to get it to do anything useful. Basically it makes
>> fixing bugs a serious burden instead of being a pleasurable session of
>> debugging and puzzle solving. I mean a Dist::Zilla based repo
>> typically doesn't even include a file that says what to do with the
>> repo to get it to build. I know I am supposed to run some "dzil"
>> command, but I tend to have to reread the docs to remember what the
>> heck that command is. It just seems like Dist::Zilla is *designed* to
>> be hostile towards third party builders who aren't used to the
>> toolchain.
>>
>> I really am reaching the point where I say "I don't do BBC support for
>> modules hosted on GitHUb that use Dist::Zilla." Module::Build is bad
>> enough, but Dist::Zilla is much much worse. I don't want to be this
>> person, if I break your code by a core change I really strongly
>> believe I should be involved in fixing it. But when people build their
>> modules using Dist::Zilla that support becomes much more costly to
>> provide, and frankly the frustration to reward seems wildly out of
>> sync with each other, especially the reward goes to someone else, but
>> I get to keep all the frustration.
>>
>> I don't know if anyone cares about this, but I feel sure that
>> Dist::Zilla could be changed to be much more friendly to people who
>> will be building other peoples repos. One thing that comes to mind is
>> maybe someone who knows Dist::Zilla can write a tool for core which
>> can "de-fang the zilla" in a github repo by downloading the latest
>> version of the release from CPAN and then inserting the build files
>> into the repo that contains the code. (Waves hands.) Or whatever, I
>> don't care really, I just don't think I should have to wait an hour
>> for cpanm to install half of CPAN to even be able to compile the code,
>>
>> Anyway, thoughts and help would be appreciated here.
>>
>
> This (among other reasons) is why my preferred usage of dzil has always
> been to regenerate the Makefile.PL and META.json into the repo.
> Unfortunately this is up to each author to decide to implement (unless they
> use my Starter::Git bundle, in which case they can simply use the
> regenerate option)
>

Barring authors ideally making their repository more contributor friendly,
my usage suggestions in the meantime would be:

use my installdeps command (or its documented equivalent commands) to
install both the dzil and distribution dependencies:
https://metacpan.org/pod/Dist::Zilla::App::Command::installdeps

use dzil build to make a build dir, dzil test to build and run the tests,
dzil run to build and run an arbitrary command, or dzil install to build
and run the tests.

You may also find my starter guide useful:
https://metacpan.org/pod/Dist::Zilla::Starter#COMMANDS

-Dan
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, Jan 18, 2023 at 12:46 PM Dan Book <grinnz@gmail.com> wrote:

> use dzil build to make a build dir, dzil test to build and run the tests,
> dzil run to build and run an arbitrary command, or dzil install to build
> and run the tests.
>

this of course should read "dzil install to build and install locally"

-Dan
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Jan 18, 2023 at 4:56:35 AM, demerphq <demerphq@gmail.com> wrote:

> I don't know if anyone cares about this, but I feel sure that
> Dist::Zilla could be changed to be much more friendly to people who
> will be building other peoples repos.


This is one of the main reasons I wrote Dist::Milla, a dzil wrapper.

https://metacpan.org/pod/Dist::Milla#Dist::Zilla-makes-contributing-difficult1

> Milla copies the plain META.json and Build.PL into the git repository you
> automatically bump on every release. [...] This means that the git
> repository can be installed as a standard CPAN distribution even without
> Dist::Zilla installed, and collaborators can just hack your modules, run
> the tests with prove -l t and send a pull request just like a normal module
> without using dzil at all.
>

That said, I think the nice thing about dzil is that once you know how to
use dzil it can be applied to any dzil distributions. That is essentially:

> cpanm Dist::Zilla
> cpanm $(dzil authordeps)
> dzil test


Tatsuhiko Miyagawa
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
* demerphq <demerphq@gmail.com> [2023-01-18 14:49:16 +0100]:

> On Wed, 18 Jan 2023 at 14:33, G.W. Haywood via perl5-porters
> <perl5-porters@perl.org> wrote:
> >
> > Hi there,
> >
> > On Wed, 18 Jan 2023, demerphq wrote:
> >
> > > I keep encountering BBC tickets for modules which have code hosted on
> > > github, but which have no actual way to build the code in the repo
> > > because they use Dist::Zilla and expect Dist::Zilla ...
> >
> > our %anathema =
> > {
> > 'Yves' => 'Dist::Zilla',
> > 'Ged' => 'github',
> > }
>
> I dont consider Dist::Zilla anathema. I just consider it needlessly
> harmful to the ecosystem. It seems like it could be changed to be less
> so. I dunno. I just dont want to spend an hour before I can even get
> to start debugging the core issue I am trying to address.

You might not superficially, but chances are one of the thousands of
modules it uses, you do.

However, I find it very useful on "fat" (and I mean morbidly obese) dev
environments where the very purpose is to test, fix, and release/PR code
that uses a dist.ini file. That is to say, Dz is a complete indulgence,
and this is generally acknowledged. You should feel ashamed for using it,
you really should. To the point Perlmonks should open up an anonymous
'confessional' section. Who'd do the absolution, I can't say especially
considering dzil easily becomes habitual. It's definitely Perl's form
of gluttony, tacked on to the pride and sloth bits. Yet we continue to
use it.

That said, I think the trick is how to isolate all the garbage it installs.
I have separate machines/VMs for this (really, 1); but have considered
that it might be pretty straightforward to provide "dzil" inside of a
Docker overlay. Just a thought. Another thought would be to have a separate
environment that does the "dzil build" bit, then take the tarball here
everything you'd want is in there (I think). However, this is more like
fixing the end result of the rendered thing, rather than the thing that
rendered it. So it's not unlike a compile step in the build process. Sort
of the autoconf before the config.

It does make things very nice for maintaining modules. Note: people should
not only be publishing their dist.ini on their $REPO, but also on CPAN.

Now if you want to know what is anathema to me, it's whatever Alien::Base
is. Appologies to Graham and all the #native warriors, but you want to
talk about a bunch of frustration for someone who must deal with it
infrequently enough as to make re-learning required every time ...

I don't expect any of this to make you feel better, but I am interested
in all the replies and what sort of workarounds are out there; the benefits
of Dist::Zill to Perl are sort of like the benefits of Moose. I know its
the secret sauce of something I love, that otherwise wouldn't exist -
including Dist::Zilla (heh), but let me be willfully ignorant without too
much work on my part.

Brett

>
> cheers,
> Yves
>
>
> --
> perl -Mre=debug -e "/just|another|perl|hacker/"

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Wed, Jan 18, 2023 at 01:56:35PM +0100, demerphq wrote:
> I keep encountering BBC tickets for modules which have code hosted on
> github, but which have no actual way to build the code in the repo
> because they use Dist::Zilla and expect Dist::Zilla to generate it all
> pre-release. This is fine for joe-random hacker worker on their own or
> in a small team with agreed build conventions and requirements. It is
> a total nightmare when you are someone like me who really has no
> interest in Dist::Zilla and who doesn't want to have to learn it just
> to fix your module when it breaks due to a core change.

dzil can be frustrating to deal with for BBC tickets (time
consumption[1], broken dependencies[2]), but I don't think it's worth
getting too excited about.

If the git repository has a Makefile.PL/Build.PL then you can work
with that.

The version on CPAN will include the Build.PL/Makefile.PL, so you can
make changes against that, if their repo has significant changes[3]
that's really their problem. It's their module, they can better adapt
any change (or choose to ignore a change.)

Tony

[1] part of dzil and its plugins is the author only needs to install
it once, so deep dependency trees don't matter much, but of course we
have a new blead each day.

[2] back when I did try to use dzil while fixing BBCs I'd often
encounter some other broken dependency deep in the dependency tree.

[3] cough, Imager right now
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Thu, 19 Jan 2023, 07:20 Tony Cook, <tony@develop-help.com> wrote:

>
> [1] part of dzil and its plugins is the author only needs to install
> it once, so deep dependency trees don't matter much, but of course we
> have a new blead each day.
>

Or every 10 minutes if dev flow is good. :-)

Yves

>
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
I disagree with you completely.

Dist::Zilla has never prevented me from updating a module and running
the test suite, and submitting patches.  I've been able to do that
without touching Dist::Zilla.

I do use it for my own modules now, but it doesn't require the latest
versions of Perl.



On 18/01/2023 12:56, demerphq wrote:
> I keep encountering BBC tickets for modules which have code hosted on
> github, but which have no actual way to build the code in the repo
> because they use Dist::Zilla and expect Dist::Zilla to generate it all
> pre-release. This is fine for joe-random hacker worker on their own or
> in a small team with agreed build conventions and requirements. It is
> a total nightmare when you are someone like me who really has no
> interest in Dist::Zilla and who doesn't want to have to learn it just
> to fix your module when it breaks due to a core change.
Re: Dist::Zilla considered harmful for Bleads Break CPAN reports. [ In reply to ]
On Thu, 19 Jan 2023, 17:47 Robert Rothenberg, <rrwo@cpan.org> wrote:

> I disagree with you completely.
>

You do? It looks to me like you aren't responding to what my post says but
to what you think my post says.


> Dist::Zilla has never prevented me from updating a module and running
> the test suite, and submitting patches. I've been able to do that
> without touching Dist::Zilla.
>

And you have a copies amount of experience fixing Blead Breaks CPAN bugs do
you? No doubt you did all that work under a synonym as I can find only a
single patch to core under your name and that was a doc fix, not likely to
create any fallout. Did I miss you feverishly working to fix BBC tickets
under this alias?

I'm being sarcastic because you post vehemently about how you disagree with
me, but seem to more or less admit you have no shared context to understand
what i am complaining about.


> I do use it for my own modules now, but it doesn't require the latest
> versions of Perl.
>

So that basically says you didn't read my post and are making a knee jerk
reaction.

It is notable that most the folks that actually do have copious experience
with fixing BBC tickets do agree with me that Dist::Zilla is a pain for the
core perl dev team. Although I admit some folks get less frustrated by it
than I do.

Let me restate something I thought I had already made clear in this thread:

I am *NOT* saying that Dist::Zilla is a bad thing, nor do I oppose peoples
use of it their own projects. All I object to is that it makes the kind of
contribution model that we use to keep CPAN up to date with core changes
unnecessarily more difficult and expensive. I also believe that if there
was a will in the Dist::Zilla community to do something about this then
they could.

All I want from this thread is that the Dist::Zilla folks put some effort
in to make it easier for the core perl dev team to keep our ecosystem
running on the latest version of perl.

Repeat: I am not saying you shouldn't use DZ or anything like that. I'm
saying that if you do, and something I do breaks your module likely I will
not put much effort into helping you fix it if I have to burn an hour just
to get your module to build.

Cheers
Yves



>
>
> On 18/01/2023 12:56, demerphq wrote:
> > I keep encountering BBC tickets for modules which have code hosted on
> > github, but which have no actual way to build the code in the repo
> > because they use Dist::Zilla and expect Dist::Zilla to generate it all
> > pre-release. This is fine for joe-random hacker worker on their own or
> > in a small team with agreed build conventions and requirements. It is
> > a total nightmare when you are someone like me who really has no
> > interest in Dist::Zilla and who doesn't want to have to learn it just
> > to fix your module when it breaks due to a core change.
>

1 2 3  View All