Mailing List Archive

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