Mailing List Archive

On Thu, Dec 23, 2021 at 10:25:25PM +0100, Leon Timmermans wrote:
> I can't help noticing that for many distributions it's rather unintuitive
> what its upstream will be. I have the general impression that it's often a
> matter of "it was orphaned, so we adopted it" more than anything else. I
> don't think that state is desirable.
>
> I would propose that we would aim to split them on a simple question "will
> most changes come from inside or outside of core". That would mean that
> e.g. Devel::PPPort would stay dist/, but something like FindBin should move
> to cpan/. That doesn't mean we should move all those things right away,
> often we should find a reliable maintainer first.

This *seems* to be what we *say* we already do. From perlhack.pod:

=head2 Patching a core module

This works just like patching anything else, with one extra
consideration.

Modules in the F<cpan/> directory of the source tree are maintained
outside of the Perl core. When the author updates the module, the
updates are simply copied into the core. See that module's
documentation or its listing on L<https://metacpan.org/> for more
information on reporting bugs and submitting patches.

In most cases, patches to modules in F<cpan/> should be sent upstream
and should not be applied to the Perl core individually. If a patch to
a file in F<cpan/> absolutely cannot wait for the fix to be made
upstream, released to CPAN and copied to blead, you must add (or
update) a C<CUSTOMIZED> entry in the F<"Porting/Maintainers.pl"> file
to flag that a local modification has been made. See
F<"Porting/Maintainers.pl"> for more details.

In contrast, modules in the F<dist/> directory are maintained in the
core.


ie

dist: we can patch it directly in blead

cpan: we should send patches upstream



And making this distinction easy to see was (also) important, which was why
we made the split like this.

I wouldn't want to get rid of that - if we re-arrange things so that we
have a directory where *some* subdirectories "shouldn't be patches" and
some should, that is also hard to follow.


Note, there is no reason to stick to just 3 subdirectories ext/ dist/ and
cpan/

We could split dist and go 4 ways:

ext:
unchanged. core-only

bundle:
what was cpan/

dist:
upstream blead, dual life

cpan:
blead can patch if needed



I think that this layout would address both concerns.


Nicholas Clark

On 12/24/21 00:56, Nicholas Clark wrote:
> On Thu, Dec 23, 2021 at 10:25:25PM +0100, Leon Timmermans wrote:
>> I can't help noticing that for many distributions it's rather unintuitive
>> what its upstream will be. I have the general impression that it's often a
>> matter of "it was orphaned, so we adopted it" more than anything else. I
>> don't think that state is desirable.
>>
>> I would propose that we would aim to split them on a simple question "will
>> most changes come from inside or outside of core". That would mean that
>> e.g. Devel::PPPort would stay dist/, but something like FindBin should move
>> to cpan/. That doesn't mean we should move all those things right away,
>> often we should find a reliable maintainer first.
>
> This *seems* to be what we *say* we already do. From perlhack.pod:
>
> =head2 Patching a core module
>
> This works just like patching anything else, with one extra
> consideration.
>
> Modules in the F<cpan/> directory of the source tree are maintained
> outside of the Perl core. When the author updates the module, the
> updates are simply copied into the core. See that module's
> documentation or its listing on L<https://metacpan.org/> for more
> information on reporting bugs and submitting patches.
>
> In most cases, patches to modules in F<cpan/> should be sent upstream
> and should not be applied to the Perl core individually. If a patch to
> a file in F<cpan/> absolutely cannot wait for the fix to be made
> upstream, released to CPAN and copied to blead, you must add (or
> update) a C<CUSTOMIZED> entry in the F<"Porting/Maintainers.pl"> file
> to flag that a local modification has been made. See
> F<"Porting/Maintainers.pl"> for more details.
>
> In contrast, modules in the F<dist/> directory are maintained in the
> core.
>
>
> ie
>
> dist: we can patch it directly in blead
>
> cpan: we should send patches upstream
>
>
>
> And making this distinction easy to see was (also) important, which was why
> we made the split like this.
>
> I wouldn't want to get rid of that - if we re-arrange things so that we
> have a directory where *some* subdirectories "shouldn't be patches" and
> some should, that is also hard to follow.
>
>
> Note, there is no reason to stick to just 3 subdirectories ext/ dist/ and
> cpan/
>
> We could split dist and go 4 ways:
>
> ext:
> unchanged. core-only
>
> bundle:
> what was cpan/
>
> dist:
> upstream blead, dual life
>
> cpan:
> blead can patch if needed
>
>
>
> I think that this layout would address both concerns.
>
>

LGTM

On Fri, 24 Dec 2021, 15:57 Nicholas Clark, <nick@ccl4.org> wrote:.

> Note, there is no reason to stick to just 3 subdirectories ext/ dist/ and
> cpan/
>
> We could split dist and go 4 ways:
>
> ext:
> unchanged. core-only
>
> bundle:
> what was cpan/
>
> dist:
> upstream blead, dual life
>
> cpan:
> blead can patch if needed
>
>
>
> I think that this layout would address both concerns
>

One thing I find annoying is having to remember which one a given module is
in. Could we maybe add another that is a symlink directory into all 4?
Maybe "modules"? Then when I'm just trying to find the code for something
and cant remember what the dist name is or I want to see an overview of
everything we include I can look there?

Would that be a step too far?

Yves

>

On Wed, Feb 23, 2022, at 8:23 PM, demerphq wrote:
> One thing I find annoying is having to remember which one a given module is in. Could we maybe add another that is a symlink directory into all 4? Maybe "modules"? Then when I'm just trying to find the code for something and cant remember what the dist name is or I want to see an overview of everything we include I can look there?

I am sympathetic to this idea, but I think it will introduce more problems than it solves. Things will get out of sync, porting tests will need to exist and get run, and so on. For me, the solution is that I guess (which is right 80% of the time) and failing that run "find | grep utf8.pm".

I'm not strongly opposed if somebody can convince me it *wouldn't* be a new, more annoying low-grade annoyance, but my gut feeling is that this won't happen.

What about this idea, which I haven't thought about for more time than it takes to type: Everything goes into one place, ./perl-lib or something, and then the build order is stored in a manifest-like file. The porting test looks for subdirectories not assigned to a build phase. I dunno, seems maybe possible. I admit this is not carefully considered.

--
rjbs

On Thu, Feb 24, 2022 at 2:23 AM demerphq <demerphq@gmail.com> wrote:

> On Fri, 24 Dec 2021, 15:57 Nicholas Clark, <nick@ccl4.org> wrote:.
>
>> Note, there is no reason to stick to just 3 subdirectories ext/ dist/ and
>> cpan/
>>
>> We could split dist and go 4 ways:
>>
>> ext:
>> unchanged. core-only
>>
>> bundle:
>> what was cpan/
>>
>> dist:
>> upstream blead, dual life
>>
>> cpan:
>> blead can patch if needed
>>
>>
>>
>> I think that this layout would address both concerns
>>
>
> One thing I find annoying is having to remember which one a given module
> is in. Could we maybe add another that is a symlink directory into all 4?
> Maybe "modules"? Then when I'm just trying to find the code for something
> and cant remember what the dist name is or I want to see an overview of
> everything we include I can look there?
>
> Would that be a step too far?
>

Much of it is functional. In particular "you probably should not commit any
edit in cpan/" is useful.

That said, I do feel your pain, and I think that adding a 5th directory for
perl modules to live in (Nicholas forgot to mention lib) would add more
confusion than it's worth.

Leon

On Thu, 24 Feb 2022 at 03:58, Leon Timmermans <fawaka@gmail.com> wrote:

> On Thu, Feb 24, 2022 at 2:23 AM demerphq <demerphq@gmail.com> wrote:
>
>> On Fri, 24 Dec 2021, 15:57 Nicholas Clark, <nick@ccl4.org> wrote:.
>>
>>> Note, there is no reason to stick to just 3 subdirectories ext/ dist/ and
>>> cpan/
>>>
>>> We could split dist and go 4 ways:
>>>
>>> ext:
>>> unchanged. core-only
>>>
>>> bundle:
>>> what was cpan/
>>>
>>> dist:
>>> upstream blead, dual life
>>>
>>> cpan:
>>> blead can patch if needed
>>>
>>>
>>>
>>> I think that this layout would address both concerns
>>>
>>
>> One thing I find annoying is having to remember which one a given module
>> is in. Could we maybe add another that is a symlink directory into all 4?
>> Maybe "modules"? Then when I'm just trying to find the code for something
>> and cant remember what the dist name is or I want to see an overview of
>> everything we include I can look there?
>>
>> Would that be a step too far?
>>
>
> Much of it is functional. In particular "you probably should not commit
> any edit in cpan/" is useful.
>
> That said, I do feel your pain, and I think that adding a 5th directory
> for perl modules to live in (Nicholas forgot to mention lib) would add more
> confusion than it's worth.
>

I think i phrased myself poorly. Using the word "modules" just muddied the
water of what I meant. I meant basically a directory which has symlinks to
the results of ls dist/ cpan/ ext/ and so forth.

In other words let say we called it "all_bundles" we would have

all_bundles/re -> ext/re
all_bundles/File-Spec -> cpan/Scalar-List-Util
all_bundles/Scalar-List-Util -> bundle/Scalar-List-Util
all_bundles/Term-Readlin -> dist/Term-ReadLine

so we would only have to update it when we add a new "bundle" or if we were
to move them between different directories. Eg, if someone decided to take
over maintenance of a "cpan" bundle (assuming the new proposed names) it
would move to the "bundle" directory, and we would change the symlink. That
would also provide long term continuity for people as well.

Cheers,
Yves

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