Mailing List Archive

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

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.

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/"

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/

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)

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

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/"

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)

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

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/

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/

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

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/"

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

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/"

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

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

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

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

* 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

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

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

>

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.

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.
>

To keep it nice an on-topic: the suggestion from Matthew Horsfall is the
way to go for you if you don't want to install Dist::Zilla once every
year/every Perl version.

If the author configured Dist::Zilla to now change the lines of code your
patch against the built code will apply without any work from the author.
If the author objects your patch because it doesn't apply, you can always
point him at his Dist::Zilla config and that he can take care of that to
make contributions easier for others including p5p.
I'm not sure if the default Dist::Zilla config does shift lines, if it does
than mainly from # ABSTRACT/Pod::Weaver.

Best regards, Alex

On Thu, 19 Jan 2023 at 11:48, Alexander Hartmaier
<alex.hartmaier@gmail.com> wrote:
>
> To keep it nice an on-topic: the suggestion from Matthew Horsfall is the way to go for you if you don't want to install Dist::Zilla once every year/every Perl version.
>
> If the author configured Dist::Zilla to now change the lines of code your patch against the built code will apply without any work from the author. If the author objects your patch because it doesn't apply, you can always point him at his Dist::Zilla config and that he can take care of that to make contributions easier for others including p5p.
> I'm not sure if the default Dist::Zilla config does shift lines, if it does than mainly from # ABSTRACT/Pod::Weaver.

It would be lovely if someone in the Dist::Zilla community hacked up a
tool for us poor core devs to use when this happens.

Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"

On Wed, Jan 18, 2023 at 1:57 PM 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.
>

I empathize with your point, but find the general tone uncomfortable.

Dist::Zilla workflows tend to prioritize the author over contributors. This
is a trade-off, but as a trade-off it makes sense in a lot of situations.
In that light, I find your "Dist::Zilla considered harmful …" and "I just
consider it needlessly harmful to the ecosystem" needlessly judgemental;
not just towards its author but also against the many CPAN authors for whom
it is a useful tool. Optimizing for BBCs only really makes sense for the
handful of dists that are regularly broken by changes in blead (e.g.
Devel::Cover, Devel::NYTProf, Data::Alias, …).

We can discuss "how to deal with dists like these" without resorting to
judgements.

Leon

On Thu, 19 Jan 2023 11:50:52 +0100
demerphq <demerphq@gmail.com> wrote:

> It would be lovely if someone in the Dist::Zilla community hacked up a
> tool for us poor core devs to use when this happens.

I mentioned it ages ago. It's called App::sourcepan.

Here let me demonstrate on Test::Vars:

$ sourcepan --git Test::Vars
Reading '/home/leo/.cpan/Metadata'
Database was generated on Thu, 12 Jan 2023 18:29:01 GMT
CPAN: HTTP::Tiny loaded ok (v0.082)
CPAN: Net::SSLeay loaded ok (v1.92)
CPAN: IO::Socket::SSL loaded ok (v2.077)
Fetching with HTTP::Tiny:
https://cpan.org/authors/01mailrc.txt.gz
Reading '/home/leo/.cpan/sources/authors/01mailrc.txt.gz'
CPAN: Compress::Zlib loaded ok (v2.201)
............................................................................DONE
Fetching with HTTP::Tiny:
https://cpan.org/modules/02packages.details.txt.gz
Reading '/home/leo/.cpan/sources/modules/02packages.details.txt.gz'
Database was generated on Thu, 19 Jan 2023 10:41:02 GMT
CPAN: HTTP::Date loaded ok (v6.05)
..............
...

GFUJI/Test-Vars-0.015.tar.gz => Test-Vars-0.015.tar.gz
Unpacked Test-Vars-0.015.tar.gz to Test-Vars
hint: Using 'master' as the name for the initial branch. This default
branch name hint: is subject to change. To configure the initial branch
name to use in all hint: of your new repositories, which will suppress
this warning, call: hint:
hint: git config --global init.defaultBranch <name>
hint:
hint: Names commonly chosen instead of 'master' are 'main', 'trunk' and
hint: 'development'. The just-created branch can be renamed via this
command: hint:
hint: git branch -m <name>
Initialized empty Git repository in /home/leo/src/Test-Vars/.git/
[master (root-commit) dd0b49a] Imported GFUJI/Test-Vars-0.015.tar.gz
52 files changed, 2139 insertions(+)
create mode 100644 Build.PL
create mode 100644 Changes
create mode 100644 LICENSE
...

leo@shy:~/src
$ cd Test-Vars/

leo@shy:~/src/Test-Vars [git]
$ git status
On branch master
nothing to commit, working tree clean

Notice that all I typed was

sourcepan --git Test::Vars
cd Test-Vars
git status

That's it. I did not have to do *any* thinking at all. I didn't even
have to go looking for a git repository link.

I now have a git working directory with a proper CPAN dist in it:

leo@shy:~/src/Test-Vars [git]
$ perl Build.PL
Creating new 'Build' script for 'Test-Vars' version '0.015'

leo@shy:~/src/Test-Vars [git]
$ ./Build
cp lib/Test/Vars.pm blib/lib/Test/Vars.pm

leo@shy:~/src/Test-Vars [git]
$ ./Build test
t/00_load.t .............. 1/1 # Testing Test::Vars/0.015
t/00_load.t .............. ok
t/01_all_vars_ok_self.t .. ok
...

If I want I can now edit any files and fiddle until the tests all pass,
then git commit / git diff / git $WHATEVER.

This is the tool I made for *this exact situation*.

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Thu, 19 Jan 2023 11:37:38 +0100, demerphq <demerphq@gmail.com> wrote:

> On Thu, 19 Jan 2023, 17:47 Robert Rothenberg, <rrwo@cpan.org> wrote:
>> Dist::Zilla has never prevented me from updating a module and runningthe test suite, and submitting patches.
>
> And you have a copies amount of experience fixing Blead Breaks CPAN bugs do you?

Honest curiosity, as someone who's completely lost count of how many patches to cpan modules they contributed: How does, in relation to factors affected by Dist::Zilla, BBC patching differ from other patching work?

--
With regards,
Christian Walde

On Thu, 19 Jan 2023 at 17:34, Christian Walde <walde.christian@gmail.com> wrote:
>
> On Thu, 19 Jan 2023 11:37:38 +0100, demerphq <demerphq@gmail.com> wrote:
>
> On Thu, 19 Jan 2023, 17:47 Robert Rothenberg, <rrwo@cpan.org> wrote:
>>
>> Dist::Zilla has never prevented me from updating a module and running
>> the test suite, and submitting patches.
>
>
> And you have a copies amount of experience fixing Blead Breaks CPAN bugs do you?
>
>
> Honest curiosity, as someone who's completely lost count of how many patches to cpan modules they contributed: How does, in relation to factors affected by Dist::Zilla, BBC patching differ from other patching work?

It differs primarily because the dependencies installation cost aren't
amortized over many patches, because the perl you build is brand new.
And if you fix the perl you have to build and install it again and
reinstall all the deps. The lifetime of an installed blead perl on my
computer is measured in days or hours, or even minutes sometimes. When
installing the dependencies for a fix lasts longer than the intended
lifetime of the perl those dependencies are installed into you can see
how frustration builds quickly. I guess the other way it differs is
that when you patch a CPAN module you are usually patching something
you want to use, or is being used by your own code, so you have an
investment to do so, and there are limited modules you need to patch.
With a BBC we might have 3 or 6 or a dozen modules to patch, one after
the other. Right now I have about 10 modules on my todo list, and I
have knocked out 3 in the past 24 hours.

With many modules, the ones based on EU::MM there is a decent chance
you can fix the BBC issue without even installing the perl that has
broken things. With some they have too many dependencies to get away
with that and you have to install the perl. Then you have to install
its deps, then you debug and patch. If you need to patch perl itself
you may have to repeat this process multiple times.

I am very thankful for cpanm and perlbrew, or it would be a total
nightmare, but these days it is relatively painless until you hit a
Dist::Zilla based module.

I guess I will resolve this in future by doing as others in this
thread suggested and simply ignoring the repos for anything that uses
Dist::Zilla and just patch against the released code, and hope that it
wasn't a waste of time doing so (it has been in the past.)

cheers,
Yves
ps: For the bulks of BBC tickets my workflow is roughly: Search module
on CPAN, find repo name, clone repo, patch, push, create a PR, report
that i have created a PR and then move on the next module.

--
perl -Mre=debug -e "/just|another|perl|hacker/"

On Thu, 19 Jan 2023 17:59:20 +0100
demerphq <demerphq@gmail.com> wrote:

> ps: For the bulks of BBC tickets my workflow is roughly: Search module
> on CPAN, find repo name, clone repo, patch, push, create a PR, report
> that i have created a PR and then move on the next module.

It sounds like the first 3 steps of that would be made simpler with my
`sourcepan` then. I'm going to keep banging on that drum a few times
more... ;)

--
Paul "LeoNerd" Evans

leonerd@leonerd.org.uk | https://metacpan.org/author/PEVANS
http://www.leonerd.org.uk/ | https://www.tindie.com/stores/leonerd/

On Thu, 19 Jan 2023 at 18:08, Paul "LeoNerd" Evans
<leonerd@leonerd.org.uk> wrote:
>
> On Thu, 19 Jan 2023 17:59:20 +0100
> demerphq <demerphq@gmail.com> wrote:
>
> > ps: For the bulks of BBC tickets my workflow is roughly: Search module
> > on CPAN, find repo name, clone repo, patch, push, create a PR, report
> > that i have created a PR and then move on the next module.
>
> It sounds like the first 3 steps of that would be made simpler with my
> `sourcepan` then. I'm going to keep banging on that drum a few times
> more... ;)

I havent ignored you. It is just that I understood your solution to be
for a slightly different problem. When i said "it would be nice if
there was a tool" what i meant was "there is a github repo that uses
Dist::Zilla, somehow download what is required from CPAN so that repo
can be patched properly without using Dist::Zila. The solution you
have is something I am going to be trying out over the next days, but
it seems like it is more about automating part of the process I dont
find that difficult or tedius, although I am sure your process is
nicer and i look forward to trying it out. If i have misunderstood
some of the finer points of your tool then bear with me and in a day
or two I will know better. :-)

cheers,
Yves


--
perl -Mre=debug -e "/just|another|perl|hacker/"

On Thu, 19 Jan 2023 17:59:20 +0100, demerphq <demerphq@gmail.com> wrote:

> On Thu, 19 Jan 2023 at 17:34, Christian Walde <walde.christian@gmail.com> wrote:
>>
>> Honest curiosity, as someone who's completely lost count of how many patches to cpan modules they contributed: How does, in relation to factors affected by Dist::Zilla, BBC patching differ from other patching work?
>
> It differs primarily because the dependencies installation cost aren't
> amortized over many patches
>
> painless until you hit a
> Dist::Zilla based module.

Appreciate the clarification. I do see the differences and I think i have a suggestion to ease your work then:

You don't actually need to use dzil in the blead perl. It is mainly just a template processor and as such agnostic from where the dist broke.

It will admittedly be a tiny bit of extra complication, but you can keep one stable perl with Dist::Zilla installed, and use this flow:

- clone repo
- switch to stable perl
- dzil build
- copy makefile.pl or build.pl from build dir back into main dir
- switch to blead perl
- patch

Maybe this helps? :)

--
With regards,
Christian Walde

On Thu, 19 Jan 2023 18:18:54 +0100, Christian Walde <walde.christian@gmail.com> wrote:

> On Thu, 19 Jan 2023 17:59:20 +0100, demerphq <demerphq@gmail.com> wrote:
>
>> On Thu, 19 Jan 2023 at 17:34, Christian Walde <walde.christian@gmail.com> wrote:
>>>
>>> Honest curiosity, as someone who's completely lost count of how many patches to cpan modules they contributed: How does, in relation to factors affected by Dist::Zilla, BBC patching differ from other patching work?
>>
>> It differs primarily because the dependencies installation cost aren't
>> amortized over many patches
>>
>> painless until you hit a
>> Dist::Zilla based module.
>
> Appreciate the clarification. I do see the differences and I think i have a suggestion to ease your work then:
>
> You don't actually need to use dzil in the blead perl. It is mainly just a template processor and as such agnostic from where the dist broke.
>
> It will admittedly be a tiny bit of extra complication, but you can keep one stable perl with Dist::Zilla installed, and use this flow:
>
> - clone repo
> - switch to stable perl
> - dzil build
> - copy makefile.pl or build.pl from build dir back into main dir
> - switch to blead perl
> - patch
>
> Maybe this helps? :)

As a quick follow-up, i just tried this with BBC-adjacent re::engine::GNU.

This can happen in stable perl, and if you do it for a bunch of different modules, you'll be reusing already installed deps and thus have very little install times:

$ git clone <repo>
$ dzil build
$ dzil authordeps --missing | cpanm
$ dzil build
$ nano dist.ini # remove [Authority] plugin
$ dzil build
$ cpanm Pod::Weaver::PluginBundle::RJBS
$ dzil build

Only this requires being done in blead perl:

$ cp re-engine-GNU-0.025/Makefile.PL .
$ perl Makefile.PL
$ make
$ make test
$ nano lib/re/engine/GNU.pm # edit in versions as per
# re-engine-GNU-0.025/lib/re/engine/GNU.pm
$ make
$ make test # PASS

--
With regards,
Christian Walde

* demerphq <demerphq@gmail.com> [2023-01-19 18:12:55 +0100]:

> On Thu, 19 Jan 2023 at 18:08, Paul "LeoNerd" Evans
> <leonerd@leonerd.org.uk> wrote:
> >
> > On Thu, 19 Jan 2023 17:59:20 +0100
> > demerphq <demerphq@gmail.com> wrote:
> >
> > > ps: For the bulks of BBC tickets my workflow is roughly: Search module
> > > on CPAN, find repo name, clone repo, patch, push, create a PR, report
> > > that i have created a PR and then move on the next module.
> >
> > It sounds like the first 3 steps of that would be made simpler with my
> > `sourcepan` then. I'm going to keep banging on that drum a few times
> > more... ;)
>
> I havent ignored you. It is just that I understood your solution to be
> for a slightly different problem. When i said "it would be nice if
> there was a tool" what i meant was "there is a github repo that uses
> Dist::Zilla, somehow download what is required from CPAN so that repo
> can be patched properly without using Dist::Zila. The solution you
> have is something I am going to be trying out over the next days, but
> it seems like it is more about automating part of the process I dont
> find that difficult or tedius, although I am sure your process is
> nicer and i look forward to trying it out. If i have misunderstood
> some of the finer points of your tool then bear with me and in a day
> or two I will know better. :-)
>
> cheers,
> Yves

I see..I think..

If the fundamental issue is that the author leaves no recourse for another
developer to work on their module other than a deceptive dist.ini; then
it is an act of professional courtesy to offer a development pathway for
contributors to help fix things.

For example, the dist.ini is just the start; the Makefile.PL, etc that the
dist.ini renders should just be available for the latest version (git tagged)
somehow so that someone wanting to test/debug/fix a specific version can not
only build it locally without installing Dist::Zilla..

Consider the following situation:

- dev X's module is broken but uses dist.ini
- dev Y wants to fix it, so they can grab the repo that contains
not only the dist.ini, but the traditional bits (Makefile.PL, etc)
so they do not need to even think about generating the Makefile.PL, etc
- dev Y does the needful; ideally this would just include changes to
module code, tests, or other bespoke Perl, XS, etc; hopefully, the
PR requires no change to dist.ini; and HOPEFULLY the module author
can take this PR and run their dist.ini "dzil release" and all is gold

The rub comes in if:

- dev Y necessarily has to make changes to Makefile.PL (,etc) and not
just the module specific Perl or XS bits - in other words, changes
that will necessarily involve modifying dist.ini and therefore puts
puts more burden on dev X (who may or may not appriate it if they
are responsive, at all)
- dev X may say, "this is great but my dist.ini" doesn't make these
changes and I need you to update the dist.ini
- dev Y balks, muttering something about newfangled kids
- dev X balks, muttering something about a lawn

The best outcome would be if:

- dev Y fixes Makefile.PL, etc
- dev X is super happy, makes the necessary updates to dist.ini,
applies the bespoke PR changes, and a new version is released to CPAN
with fixes

What's the solution there? It's the age old issue of dealing with
rendered things like object files or HTML from templates. It is a
kind of meta compiling step and the dist.ini is the meta makefile.

I don't think there is a pure technical solution. There needs to be some
agreed upon "standard" here, and to get the largest mindshare it needs
to be the lowest common denominator.

Maybe the river factor (how far upstream a module is) or the "bus" factor
can play a part here - basically saying, the more critical module is or
how dependent it is on one person to release it, the less appropriate it
is to rely on dist.ini.

In the example above,

- dev Y treats Makefile.PL as "truth" and solid ground
- dev X treats Makefile.PL, etc as disposible artifacts

And ultimately, this is where the conflict lies as far as I can tell. IMO,
I think module authors should use what they want, but publish the latest
"artifacts" (that dev Y wants/needs) and not forcing contributors to use
Dist::Zilla - and the more critical your module is, the more "dev X" should
feel obligated to treat dzil as the secret shame it really should be.

Now if Dist::Zilla or work-withs/work-alikes can deal with this artifact
versus non-artifact thing, then maybe a 100% technical solution could help
here. I just don't see it. A lot of people, myself included, use dist.ini and
do not even keep Makefile.PL in the git repo - this is what the CPAN tgz is
for! (right?) :-)

Cheers,
Brett

>
>
> --
> 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

On Thu, Jan 19, 2023 at 5:59 PM demerphq <demerphq@gmail.com> wrote:

> It differs primarily because the dependencies installation cost aren't
> amortized over many patches, because the perl you build is brand new.
> And if you fix the perl you have to build and install it again and
> reinstall all the deps.
>

This is not true. You can use your installed perl to build a distdir with
dzil, and then use bleadperl to build the dist. I don't think the problem
you just described actually exists.

Leon

On Thu, Jan 19, 2023, at 05:37, demerphq wrote:
> On Thu, 19 Jan 2023, 17:47 Robert Rothenberg, <rrwo@cpan.org> wrote:
>> 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?

This is really uncalled for.

--
rjbs

On Fri, 20 Jan 2023, 07:51 Leon Timmermans, <fawaka@gmail.com> wrote:

> On Thu, Jan 19, 2023 at 5:59 PM demerphq <demerphq@gmail.com> wrote:
>
>> It differs primarily because the dependencies installation cost aren't
>> amortized over many patches, because the perl you build is brand new.
>> And if you fix the perl you have to build and install it again and
>> reinstall all the deps.
>>
>
> This is not true. You can use your installed perl to build a distdir with
> dzil, and then use bleadperl to build the dist. I don't think the problem
> you just described actually exists.
>

Obviously there is a problem. If there is a procedure to do this it isn't
well advertised or more core hackers in this thread would know about it.

Yves

On Fri, Jan 20, 2023 at 1:28 AM demerphq <demerphq@gmail.com> wrote:

>
>
> On Fri, 20 Jan 2023, 07:51 Leon Timmermans, <fawaka@gmail.com> wrote:
>
>> On Thu, Jan 19, 2023 at 5:59 PM demerphq <demerphq@gmail.com> wrote:
>>
>>> It differs primarily because the dependencies installation cost aren't
>>> amortized over many patches, because the perl you build is brand new.
>>> And if you fix the perl you have to build and install it again and
>>> reinstall all the deps.
>>>
>>
>> This is not true. You can use your installed perl to build a distdir with
>> dzil, and then use bleadperl to build the dist. I don't think the problem
>> you just described actually exists.
>>
>
> Obviously there is a problem. If there is a procedure to do this it isn't
> well advertised or more core hackers in this thread would know about it.
>

Not really. Both me and Mithaldu immediately noticed the problem as soon as
you actually described your workflow. If you had done that in your OP this
thread would have been a lot shorter.

Leon

On Fri, 20 Jan 2023 01:28:12 +0100, demerphq <demerphq@gmail.com> wrote:
> On Fri, 20 Jan 2023, 07:51 Leon Timmermans, <fawaka@gmail.com> wrote:
>> On Thu, Jan 19, 2023 at 5:59 PM demerphq <demerphq@gmail.com> wrote:
>>> It differs primarily because the dependencies installation cost aren't
>>> amortized over many patches, because the perl you build is brand new.
>>> And if you fix the perl you have to build and install it again and
>>> reinstall all the deps.
>>
>> This is not true. You can use your installed perl to build a distdir with dzil, and then use bleadperl to build the >>dist. I don't think the problem you just described actually exists.
>
> Obviously there is a problem. If there is a procedure to do this it isn't well advertised or more core hackers in this >thread would know about it.

The problem here was kind of unavoidable, because one side expected a thing to be used in the only way that seems sensible to them and had no way to anticipate an alternative, and the other side used it not knowing that that kind of expectation could've existed.

You approached it with core dev brain, wherein your first step of order is "compile a perl to do things in".

Meanwhile dzil and everybody working on it is toolchain-brained, wherein the first step is "use your home perl, whatever it may be, to create a tar ball which is then expected to run on mostly all other perls (until rjbs has deprecated cpan from all but the most recent perl)".

This is such a niche interaction that the venn diagram of people struggling with it is basically two circles touching slightly, which also means documenting that would mean documenting in dzil what it means to do toolchain or cpan author stuff conceptually, which would be way out of scope; and then also run an ad campaign for that.

What would have helped this situation is if both sides of the matter had treated it as a bug report.

A useful bug report follows this schema:

# summary

# repro steps

# actual outcome

# expected outcome

Had your original message followed that schema, a resolution would have been achieved considerably more quickly.

That said, had everyone else recognized that it was a bug report in an unfortunate format and proceeded in primarily *asking questions* to extract the above schema, a resolution would also have been achieved more quickly.

--
With regards,
Christian Walde

* Christian Walde <walde.christian@gmail.com> [2023-01-20 20:40:34 +0100]:

> On Fri, 20 Jan 2023 01:28:12 +0100, demerphq <demerphq@gmail.com> wrote:
> > On Fri, 20 Jan 2023, 07:51 Leon Timmermans, <fawaka@gmail.com> wrote:
> > > On Thu, Jan 19, 2023 at 5:59 PM demerphq <demerphq@gmail.com> wrote:
> > > > It differs primarily because the dependencies installation cost aren't
> > > > amortized over many patches, because the perl you build is brand new.
> > > > And if you fix the perl you have to build and install it again and
> > > > reinstall all the deps.
> > >
> > > This is not true. You can use your installed perl to build a distdir with dzil, and then use bleadperl to build the >>dist. I don't think the problem you just described actually exists.
> >
> > Obviously there is a problem. If there is a procedure to do this it isn't well advertised or more core hackers in this >thread would know about it.
>
> The problem here was kind of unavoidable, because one side expected a thing to be used in the only way that seems sensible to them and had no way to anticipate an alternative, and the other side used it not knowing that that kind of expectation could've existed.
>
> You approached it with core dev brain, wherein your first step of order is "compile a perl to do things in".
>
> Meanwhile dzil and everybody working on it is toolchain-brained, wherein the first step is "use your home perl, whatever it may be, to create a tar ball which is then expected to run on mostly all other perls (until rjbs has deprecated cpan from all but the most recent perl)".
>
> This is such a niche interaction that the venn diagram of people struggling with it is basically two circles touching slightly, which also means documenting that would mean documenting in dzil what it means to do toolchain or cpan author stuff conceptually, which would be way out of scope; and then also run an ad campaign for that.
>
> What would have helped this situation is if both sides of the matter had treated it as a bug report.
>
> A useful bug report follows this schema:
>
> # summary
>
> # repro steps
>
> # actual outcome
>
> # expected outcome
>
> Had your original message followed that schema, a resolution would have been achieved considerably more quickly.
>
> That said, had everyone else recognized that it was a bug report in an unfortunate format and proceeded in primarily *asking questions* to extract the above schema, a resolution would also have been achieved more quickly.

The non-zero circle overlap still means that dist.ini should not be
required to work on a certain class critical modules, this means the
build artifacts it produces are more precious than the dist.ini itself.
For 99.9% of CPAN, this is not the case; maybe more. Where that cut off
is, is not for me to say. But I can imagine working on some forward
version of perl using a well tuned workflow, running into issues that
you can't build Dist::Zilla* using it for some unrelated issue/module I
imagine can be absolutley infuriating. Unless I am misunderstanding the
whole issue, I can see why it is a flash point - even if for a small
number of individuals.

* look at this thing - https://cpandeps.grinnz.com/?dist=Dist-Zilla,
at at first blush is doesn't do the dependencies for the dependencies;

* maybe not as bad as "Acme::Mom::Yours - Your mom is so fat she takes 2
months to compile" (don't get mad at me, it's not my module)

* and imagine how fun that might be if perl was ever distributed requiring
SSL support (which I have found to be a nightmare, specifically using
perlbrew on NetBSD..but I digress)

Cheers,
Brett

>
> --
> With regards,
> Christian Walde

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native

On Fri, 20 Jan 2023 21:29:40 +0100, Oodler 577 <oodler577@sdf-eu.org> wrote:

> I can imagine working on some forward
> version of perl using a well tuned workflow, running into issues that
> you can't build Dist::Zilla

Maybe it's a language issue i am running into, not being a native speaker, but this seems to indicate to me you are indeed misunderstanding.

As has been said multiple times now:

Do not run dzil on your blead perl. There is no reason to think that is necessary at all.

--
With regards,
Christian Walde

On Sat, 21 Jan 2023, 05:16 Christian Walde, <walde.christian@gmail.com>
wrote:

> On Fri, 20 Jan 2023 21:29:40 +0100, Oodler 577 <oodler577@sdf-eu.org>
> wrote:
>
> > I can imagine working on some forward
> > version of perl using a well tuned workflow, running into issues that
> > you can't build Dist::Zilla
>
> Maybe it's a language issue i am running into, not being a native speaker,
> but this seems to indicate to me you are indeed misunderstanding.
>
> As has been said multiple times now:
>
> Do not run dzil on your blead perl. There is no reason to think that is
> necessary at all.
>

See that is part of the problem. You know that, I guess it's well known
amongst users. But how is someone how isn't a user supposed to know that?

The baseline is EUMM. I would never build a BBC module with an old EUMM.
For all I know the thing that is broken is the interaction with the new
EUMM. Don't forget an internal change can break *anything*, especially
regex engine changes which is where I come in very often. Outside of core
development I think there is a general expectation that the modules
included with perl are tested to a very high level, and are proven
reliable, so you assume other things are broken first. In core dev you have
to assume anything could be broken.

Whereas it seems DZ breaks this model. I definitely would not normally
assume it's ok to use an old perl to set up the testing on a new perl. Now
I do, I guess, it still makes me uneasy but I'll get over it.

I didn't file this as a *bug* because it seems like DZ is not failing to do
what it intends to do, it appears to be specifically designed to work in a
way that allows its users to set up repositories that have no standard
files that are normally used to build. Just a cryptic initial file. DZ
could strongly encourage users to add a HOWTOBUILD.txt to their repo, it
could strongly encourage people to keep their last Makefile.PL or Build.PL
around, etc, etc, I'm sure we all can think of a bunch of approaches that
would make things go smoother when a newbie encounters such a repo. That it
does not do these things is not a *bug* really, it's a design decision and
maybe an oversight. But it's not a bug.

In another post Leon claims there is no problem because you and he knows
the solution. He misses that the problem is precisely that this solution
is opaque, and not obvious to the uninitiated. If DZ insisted or strongly
encoraged having a file on disk with some basic instructions this thread
wouldn't have happened. I and the other core devs and non DZ users who have
encountered this would have read the file and followed instructions.

The reason I think DZ is harmful to the Perl ecosystem is precise because
of this lack of transparency. Perl is already cryptic enough, having loads
of cpan related repos on github with no "readme" files or instructions etc
just makes it more likely that someone incidentally encountering them will
have no idea what to do with them get frustrated and go away thinking our
community is really backwards. People can disagree all they want with that
point of view, they can call it judgemental or think it's an insult. That
is ok, I'll just continue thinking they are in denial as our community
shrinks and withers away.

I feel that our community is in a long slow decline. We don't attract new
devs. Many of the devs left seems more protective of their habits and
preferences and prerogatives than on ensuring our community grows. I love
perl, and I want to see it continue for many years to come and id like see
fresh faces get involved. that is why I continue hacking core and why I
focus on the parts I do. Bug fixes, stability, error handling, regex engine
(one of the few places where we still have a strong influence on the wider
computing community) etc.

I want to make it easier for people to join our community, I want people to
see perl as *fun*. Frankly if someone's first encounter with perl is a DZ
github repo with no build instructions I think they will walk away thinking
we are *fun*.

I think the DZ community could pretty quickly turn this around if they
want. I was hoping that they would respond as I would have to my post "oh
shit, I didn't think of *that*, let's fix it".

I guess my use of the historic term "x considered harmful" was counter
productive. I had expected the type of people who are on the p5p list to
know the history of that term which I believe goes back to Djikstra's paper
on goto from 1968.

The purpose of such statements is not to insult people who use the thing
considered harmful, nor necessarily to completely eliminate the thing
considered harmful but rather it is to encourage learning and innovation.
55 years after that seminal paper we still have goto statements, but we
know that they should be used judiciously and usually in forms that make
them safe (loop operators, subroutine calls, etc).

What I hope comes out of this thread is a recognition that the opaqueness
of the current DZ posture changes towards transparency. All it's got to do
is warn and complain there is novstandard HOWTOBUILD.txt[1] in the
directory and over the following months I bet we'd start seeing those files
solve the transparency problem.

Sorry for the long post,

Cheers
Yves
[1] whatever it's called. I didn't say README because cpan issues.

>

On Fri, Jan 20, 2023, at 21:11, demerphq wrote:
> I guess my use of the historic term "x considered harmful" was counter productive. I had expected the type of people who are on the p5p list to know the history of that term which I believe goes back to Djikstra's paper on goto from 1968.

Correct, and in that paper, Djikstra is calling for goto to be abolished.

--
rjbs

On Fri, Jan 20, 2023 at 6:12 PM demerphq <demerphq@gmail.com> wrote:

> The baseline is EUMM. I would never build a BBC module with an old EUMM.
> For all I know the thing that is broken is the interaction with the new
> EUMM. Don't forget an internal change can break *anything*, especially
> regex engine changes which is where I come in very often. Outside of core
> development I think there is a general expectation that the modules
> included with perl are tested to a very high level, and are proven
> reliable, so you assume other things are broken first. In core dev you have
> to assume anything could be broken.
>

You're certainly free to build a module, any module, with the newest EUMM,
or even on your freshly-compiled bleadperl if you like. Christian's point,
which I'm not sure you have understood yet, is that you should not _build
the build_ with bleadperl. Build the distribution (getting you to the point
where you have a tarball containing a Makefile.PL or a Build.PL) with your
normal stock perl on your desktop (that's the "dzil build" step) if you
like, or download the distribution from cpan. Then untar the distribution
and run "perl Makefile.PL; make; make test" on it in your bleadperl, if you
like (but of course then you'll have to install all runtime prerequisites).

Whereas it seems DZ breaks this model. I definitely would not normally
> assume it's ok to use an old perl to set up the testing on a new perl. Now
> I do, I guess, it still makes me uneasy but I'll get over it.
>

The purpose of your testing is to test the runtime functionality of the
distribution against bleadperl. It's not to test the toolchain's ability to
create the tarball. So you can use any old perl (that's new enough) to do
that part, or just download what was published to cpan.

I didn't file this as a *bug* because it seems like DZ is not failing to do
> what it intends to do, it appears to be specifically designed to work in a
> way that allows its users to set up repositories that have no standard
> files that are normally used to build. Just a cryptic initial file. DZ
> could strongly encourage users to add a HOWTOBUILD.txt to their repo
>

And many people do. I publish a file that looks like this (appropriately
templated) in every distribution I ship:
https://metacpan.org/release/ETHER/Class-Method-Modifiers-2.14/source/CONTRIBUTING

I trust that this is clear enough that should you want to patch this
distribution, you know what to do without using Dist::Zilla.

I think the DZ community could pretty quickly turn this around if they
> want. I was hoping that they would respond as I would have to my post "oh
> shit, I didn't think of *that*, let's fix it".
>

They're/we're not responding like that because we HAVE thought of those
things, and put in place mechanisms to make things better.

What I hope comes out of this thread is a recognition that the opaqueness
> of the current DZ posture changes towards transparency. All it's got to do
> is warn and complain there is novstandard HOWTOBUILD.txt[1] in the
> directory and over the following months I bet we'd start seeing those files
> solve the transparency problem.
>

I don't think it's terribly opaque; you only had to ask.

demerphq wrote:
>
> [...] But how is someone how isn't a user supposed to know that?
>
> The baseline is EUMM. I would never build a BBC module with an old EUMM. For all I know the thing that is broken is the interaction with the new EUMM.

It occurs to me that maybe we are talking about two entirely different kinds of "build" here. If so, perhaps the documentation could be clarified.

- DZ uses "build the dist" only in the sense of assembling a tarball that can be uploaded to the CPAN.

- EUMM / MB use "build the dist" primarily in the sense of preparing a tarball downloaded from CPAN for installation.

DZ tries to address this briefly in the abstract ("installer not included!") and module descriptions, but I suppose the difference might not be terribly obvious to a reader who is unfamiliar with DZ.


> [...] Frankly if someone's first encounter with perl is a DZ github repo with no build instructions I think they will walk away thinking we [aren't] *fun*.
>
> I think the DZ community could pretty quickly turn this around if they want.

Yeah. I have personally had this experience with others' repos and have since made a point of including brief instructions in my own GitHub readmes. Fundamentally, this isn't the fault of DZ though; it's really the fault of the repo owner and it's not limited to DZ or even to Perl.

Similarly, many Perl GH repo owners don't provide a link to MetaCPAN. It's a tiny thing, but such a link does make it slightly easier for everyone, especially for first timers.


> All it's got to do is warn and complain there is novstandard HOWTOBUILD.txt[1] in the directory and over the following months I bet we'd start seeing those files solve the transparency problem.

Assuming the repo owners actually write and commit that file. I suspect a good portion of them won't because not having read this thread, they don't understand the problem.


--
Arne Johannessen
<https://arne.johannessen.de/>

On Sat, 21 Jan 2023, 10:53 Ricardo Signes, <perl.p5p@rjbs.manxome.org>
wrote:

> On Fri, Jan 20, 2023, at 21:11, demerphq wrote:
>
> I guess my use of the historic term "x considered harmful" was counter
> productive. I had expected the type of people who are on the p5p list to
> know the history of that term which I believe goes back to Djikstra's paper
> on goto from 1968.
>
>
> Correct, and in that paper, Djikstra is calling for goto to be abolished.
>

I think he was using hyperbole to get people to think out of the box and to
encourage change and innovation. As was I.

I regret that my intentions seem to have back fired, and i regret that you
are offended by my words, but I stand by the core of my view. Simple
changes could turn this around over the long term.

It's up to you if you want to focus only on my choice of words or if you
want to respond to the real message I was trying to send.

Anyway, i guess this thread has come to a conclusion. I'll go back to my
core mission of making perl better now and leave the future of DZ to you.

Yves
Ps. I had no idea you were the DZ dude, I hadn't noticed that until after
the fact. Had I then I would have cc'd you, I apologize for the lack of
professional courtesy by not doing so.

On Sat, 21 Jan 2023, 11:39 Arne Johannessen via perl5-porters, <
perl5-porters@perl.org> wrote:

> demerphq wrote:
> >
> > All it's got to do is warn and complain there is novstandard
> HOWTOBUILD.txt[1] in the directory and over the following months I bet we'd
> start seeing those files solve the transparency problem.
>
> Assuming the repo owners actually write and commit that file. I suspect a
> good portion of them won't because not having read this thread, they don't
> understand the problem.
>

DZ could package its own standard file and whine, complain, stomp its feet
and throw its toys out the pram if you don't include it or provide a
replacement.

Yves

>

On Fri, Jan 20, 2023 at 9:12 PM demerphq <demerphq@gmail.com> wrote:

>
>
> On Sat, 21 Jan 2023, 05:16 Christian Walde, <walde.christian@gmail.com>
> wrote:
>
>> On Fri, 20 Jan 2023 21:29:40 +0100, Oodler 577 <oodler577@sdf-eu.org>
>> wrote:
>>
>> > I can imagine working on some forward
>> > version of perl using a well tuned workflow, running into issues that
>> > you can't build Dist::Zilla
>>
>> Maybe it's a language issue i am running into, not being a native
>> speaker, but this seems to indicate to me you are indeed misunderstanding.
>>
>> As has been said multiple times now:
>>
>> Do not run dzil on your blead perl. There is no reason to think that is
>> necessary at all.
>>
>
> See that is part of the problem. You know that, I guess it's well known
> amongst users. But how is someone how isn't a user supposed to know that?
>
> The baseline is EUMM. I would never build a BBC module with an old EUMM.
> For all I know the thing that is broken is the interaction with the new
> EUMM. Don't forget an internal change can break *anything*, especially
> regex engine changes which is where I come in very often. Outside of core
> development I think there is a general expectation that the modules
> included with perl are tested to a very high level, and are proven
> reliable, so you assume other things are broken first. In core dev you have
> to assume anything could be broken.
>
> Whereas it seems DZ breaks this model. I definitely would not normally
> assume it's ok to use an old perl to set up the testing on a new perl. Now
> I do, I guess, it still makes me uneasy but I'll get over it.
>
> I didn't file this as a *bug* because it seems like DZ is not failing to
> do what it intends to do, it appears to be specifically designed to work in
> a way that allows its users to set up repositories that have no standard
> files that are normally used to build. Just a cryptic initial file. DZ
> could strongly encourage users to add a HOWTOBUILD.txt to their repo, it
> could strongly encourage people to keep their last Makefile.PL or Build.PL
> around, etc, etc, I'm sure we all can think of a bunch of approaches that
> would make things go smoother when a newbie encounters such a repo. That it
> does not do these things is not a *bug* really, it's a design decision and
> maybe an oversight. But it's not a bug.
>
> In another post Leon claims there is no problem because you and he knows
> the solution. He misses that the problem is precisely that this solution
> is opaque, and not obvious to the uninitiated. If DZ insisted or strongly
> encoraged having a file on disk with some basic instructions this thread
> wouldn't have happened. I and the other core devs and non DZ users who have
> encountered this would have read the file and followed instructions.
>
> The reason I think DZ is harmful to the Perl ecosystem is precise because
> of this lack of transparency. Perl is already cryptic enough, having loads
> of cpan related repos on github with no "readme" files or instructions etc
> just makes it more likely that someone incidentally encountering them will
> have no idea what to do with them get frustrated and go away thinking our
> community is really backwards. People can disagree all they want with that
> point of view, they can call it judgemental or think it's an insult. That
> is ok, I'll just continue thinking they are in denial as our community
> shrinks and withers away.
>
> I feel that our community is in a long slow decline. We don't attract new
> devs. Many of the devs left seems more protective of their habits and
> preferences and prerogatives than on ensuring our community grows. I love
> perl, and I want to see it continue for many years to come and id like see
> fresh faces get involved. that is why I continue hacking core and why I
> focus on the parts I do. Bug fixes, stability, error handling, regex engine
> (one of the few places where we still have a strong influence on the wider
> computing community) etc.
>
> I want to make it easier for people to join our community, I want people
> to see perl as *fun*. Frankly if someone's first encounter with perl is a
> DZ github repo with no build instructions I think they will walk away
> thinking we are *fun*.
>
> I think the DZ community could pretty quickly turn this around if they
> want. I was hoping that they would respond as I would have to my post "oh
> shit, I didn't think of *that*, let's fix it".
>
> I guess my use of the historic term "x considered harmful" was counter
> productive. I had expected the type of people who are on the p5p list to
> know the history of that term which I believe goes back to Djikstra's paper
> on goto from 1968.
>
> The purpose of such statements is not to insult people who use the thing
> considered harmful, nor necessarily to completely eliminate the thing
> considered harmful but rather it is to encourage learning and innovation.
> 55 years after that seminal paper we still have goto statements, but we
> know that they should be used judiciously and usually in forms that make
> them safe (loop operators, subroutine calls, etc).
>
> What I hope comes out of this thread is a recognition that the opaqueness
> of the current DZ posture changes towards transparency. All it's got to do
> is warn and complain there is novstandard HOWTOBUILD.txt[1] in the
> directory and over the following months I bet we'd start seeing those files
> solve the transparency problem.
>
> Sorry for the long post,
>
> Cheers
> Yves
> [1] whatever it's called. I didn't say README because cpan issues.
>

I can assure you quite emphatically, all of this has been discussed ad
nauseum in the dzil community. At the end of the day it is a powerful and
flexible tool which is serving a huge variety of authors' needs, and is
directly and indirectly responsible for quite a lot of CPAN development
which would not have happened otherwise, and that has several unfortunate
tradeoffs.

My efforts to make usage of it more contributor friendly involve the
Starter::Git plugin bundle which includes an option for easy regeneration
of these and other files, perhaps the regenerate phase (created by kentnl)
and rationale for using it could be integrated into core dzil but it is
still a rather new concept for a quite thinly spread community to diffuse.

You have to understand, dzil can't simply start doing things it hasn't done
before as its behavior is largely adherent to the specific set of plugins
the author has decided to configure, there is very little that happens "by
default", only sets of behavior encouraged by the core bundle. Changing
behavior in a way that causes `dzil build/dzil release` to break on an
unchanged configuration would exacerbate the issues you encountered trying
to use it, as I'm sure you're aware how modules can languish with whatever
standards worked to release them at the time.

And that's on top of the usual difficulty of deciding what "the right
behavior" evolves to. Starter::Git is my perception of what that should be,
for the most part, and is intentionally meant to be unopinionated while
also providing opinionated options and a forward compatible revision
mechanism, but even so an author must decide to change to a new revision,
in case it introduces some incompatibility to the build process.

So feel free to make suggestions for courses of action to dzil itself, and
perhaps it could drive discussion on improving the state of things among
those knowledgeable of the ecosystem, but be aware complaints and "can't
you just" suggestions are likely to be counterproductive to your goals.

-Dan

On 21/01/2023 02:11, demerphq wrote:
>
> I feel that our community is in a long slow decline. We don't attract
> new devs.  ...
>
> I want to make it easier for people to join our community, I want
> people to see perl as *fun*. Frankly if someone's first encounter with
> perl is a DZ github repo with no build instructions I think they will
> walk away thinking we are *fun*.

What you responded to me a couple of days earlier does not seem like a
way of encouraging new devs:

> 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.

Obviously you have a different perspective.

It would be much more productive if instead of criticising the use of a
tool that makes CPAN author's lives easier, you come up with suggestions
on how they can change how they use it make things easier for people
like yourself who test modules against blead Perls.

Hint: maybe work with the Dist::Zilla author to add a setting or plugin
to make life easier for people testing modules against blead Perls.

The use of Dist::Zilla not only benefits authors, it benefits the entire
community since it limits common release breakages from being uploaded
to CPAN.

An author using Dist::Zilla means that they can focus on the code and
avoid many of bureaucratic errors that can break releases:

- Modules have consistent version numbers and documentation;

- Prerequisites are properly declared;

- Makefile.PL, MANIFEST and README are up-to-date;

- An up-to-date cpanfile is generated, which allows devs to work on the
module without installing prerequisites globally;

- Quality control author tests can be run before releasing, to avoid
other common mistakes like POD errors etc;

* demerphq <demerphq@gmail.com> [2023-01-21 10:11:37 +0800]:

> On Sat, 21 Jan 2023, 05:16 Christian Walde, <walde.christian@gmail.com>
> wrote:
>
> > On Fri, 20 Jan 2023 21:29:40 +0100, Oodler 577 <oodler577@sdf-eu.org>
> > wrote:
> >
> > > I can imagine working on some forward
> > > version of perl using a well tuned workflow, running into issues that
> > > you can't build Dist::Zilla
> >
> > Maybe it's a language issue i am running into, not being a native speaker,
> > but this seems to indicate to me you are indeed misunderstanding.
> >
> > As has been said multiple times now:
> >
> > Do not run dzil on your blead perl. There is no reason to think that is
> > necessary at all.
> >
>
> See that is part of the problem. You know that, I guess it's well known
> amongst users. But how is someone how isn't a user supposed to know that?
>
<snip>
>
> The reason I think DZ is harmful to the Perl ecosystem is precise because
> of this lack of transparency. Perl is already cryptic enough, having loads
> of cpan related repos on github with no "readme" files or instructions etc
> just makes it more likely that someone incidentally encountering them will
> have no idea what to do with them get frustrated and go away thinking our
> community is really backwards. People can disagree all they want with that
> point of view, they can call it judgemental or think it's an insult. That
> is ok, I'll just continue thinking they are in denial as our community
> shrinks and withers away.
>
> I feel that our community is in a long slow decline. We don't attract new
> devs. Many of the devs left seems more protective of their habits and
> preferences and prerogatives than on ensuring our community grows. I love
> perl, and I want to see it continue for many years to come and id like see
> fresh faces get involved. that is why I continue hacking core and why I
> focus on the parts I do. Bug fixes, stability, error handling, regex engine
> (one of the few places where we still have a strong influence on the wider
> computing community) etc.
>
> I want to make it easier for people to join our community, I want people to
> see perl as *fun*. Frankly if someone's first encounter with perl is a DZ
> github repo with no build instructions I think they will walk away thinking
> we are *fun*.

A community that "prides" it self in vices (pride, envy, sloth (laziness)) is in
decline? *mild shock*; what we're facing here is the addition of gluttony.

I mean, dzil.org's HTML starts with,

<html>
<head>
<title>Dist::Zilla - Maximum Overkill for CPAN Authors</title>
<link rel='stylesheet' type='text/css' href='style.css' />
<meta name='viewport' content='width=device-width,initial-scale=1'>
</head>

> Maximum Overkill

Maybe add anger? I am kidding of course, but this really sums it up. Do
you want maximum overkill in fragile intersections of perl, critical
modules, and a short list of developers willing to go there?

Although, this does remind me of that 80s movie where the alien proble
passes over the earth, and all machines turn on their humans. I hope
that never happens to Perl <_< ... >_>

>
> I think the DZ community could pretty quickly turn this around if they
> want. I was hoping that they would respond as I would have to my post "oh
> shit, I didn't think of *that*, let's fix it".
>
> I guess my use of the historic term "x considered harmful" was counter
> productive. I had expected the type of people who are on the p5p list to
> know the history of that term which I believe goes back to Djikstra's paper
> on goto from 1968.

I appreciated it. There's also "no silver bullet" .. and look Perl has a C<goto>,
and last time I checked is running low on silver bullets. xD

>
> The purpose of such statements is not to insult people who use the thing
> considered harmful, nor necessarily to completely eliminate the thing
> considered harmful but rather it is to encourage learning and innovation.
> 55 years after that seminal paper we still have goto statements, but we
> know that they should be used judiciously and usually in forms that make
> them safe (loop operators, subroutine calls, etc).
>
> What I hope comes out of this thread is a recognition that the opaqueness
> of the current DZ posture changes towards transparency. All it's got to do
> is warn and complain there is novstandard HOWTOBUILD.txt[1] in the
> directory and over the following months I bet we'd start seeing those files
> solve the transparency problem.

If it counts, I agree with your point and you have a right say it. It's coming
from a place of charity, and that is clear to me, at least. I hope some good
will come from it, even if it's just documentation and to admit openly that I like
Dist::Zilla like a fat kid likes cake.

Cheers,
Brett

>
> Sorry for the long post,
>
> Cheers
> Yves
> [1] whatever it's called. I didn't say README because cpan issues.
>
> >

--
--
oodler@cpan.org
oodler577@sdf-eu.org
SDF-EU Public Access UNIX System - http://sdfeu.org
irc.perl.org #openmp #pdl #native