Re: Supporting a perl without . in @INC

[Olivier Mengué]

Hi Todd,

When I started to seriously code in Perl 10 years ago (going besides
scripts to modules and CPAN distributions) I immediately thought: "Having
'.' in @INC doesn't seem a good idea. It could be exploited in a similar
way as having '.' in $ENV{PATH}". But Perl was already 20 years old, CPAN
10 years old and I thought it was already too late for a fix. So I have
started to write test suite code assuming the tests were run from the root
of the distribution and that the root of the distribution was in @INC. So I
wrote many tests modules in a directory t/lib and teir package names start
with "t::lib::" so I can just "use t::lib::TestModule". And I'm not alone
using that style: http://grep.cpan.me/?q=t%3A%3Alib%3A%3A

So I don't think your major break can avoid a major effort to patch CPAN
and DarkPAN code. Either with new fixed CPAN releases or with distroprefs.


> What at this point I feel is lacking is agreement and/or discussion that
the above is the correct approach to solving this problem.

A few questions:
- If the CPAN clients and the modules installer will get
PERL_USE_UNSAFE_INC=1 built-in, I don't see how I will be able build an
environment to test my CPAN distributions that doesn't have . in @INC at
all. So it seems that in the name of preserving backwards compatibility you
are stopping the move towards your long term goal. Or did I miss something?
- If the testsuite runs with PERL_USE_UNSAFE_INC=1, but once installed the
runtime environment is not the same, issues with @INC will just be hidden
in the test run to be discovered at runtime. Adding "use lib '.';" at the
top of each test script will hide issues in the same way. So what's the
point of running the testsuite if it can't show issues?

But I have another proposal. Instead of modifying CPAN clients, builders
and App::Prove to inject '.' into @INC, what about instead injecting in
@INC the *absolute path of the root of the distribution* being
configured/built/tested/installed? I think that this would considerably
reduce the number of side effects and it would help to really isolate
runtime code that relies on '.' being in @INC (assuming that code is
covered by a testsuite).

Olivier Mengué.

2017-01-16 18:06 GMT+01:00 Todd Rinaldo <to...@cpanel.net>:

> All,
>
> Currently in blead is a change that will begin breaking many CPAN
> installs. This is a result of a non-default change to perl builds which
> removes . from @INC. There is currently a separate proposal (
> https://rt.perl.org/Public/Bug/Display.html?id=130467 )being discussed to
> remove . from @INC by default in 5.26.
>
> More information on the impact of this can also be found here.
> http://blogs.perl.org/users/todd_rinaldo/2016/11/how-removing-from-inc-is-
> about-to-break-cpan.html
>
> As I understand things, this is the closest thing to a mailing list for
> the toolchain group, so I'm trying this list first.
>
> In order to action RT 130467 without completely breaking CPAN, I propose
> the following patches to CPAN install related modules to fix the problem:
>
> * Inject PERL_USE_UNSAFE_INC=1 into the environment early in the following
> clients. This assures that everything spawned by these clients gets . in
> @INC during test/install.
> CPAN
> CPANPLUS
> App::cpanminus
>
> * Inject PERL_USE_UNSAFE_INC=1 into TAP::Harness to support ad-hoc use of
> prove. (Leon is already working on this)
>
> * Inject PERL_USE_UNSAFE_INC=1 into install modules to try to address as
> many Makefile.PL missing . in @INC issues as possible:
> ExtUtils::MakeMaker
> Module::Build
> Module::Build::Tiny
>
> What at this point I feel is lacking is agreement and/or discussion that
> the above is the correct approach to solving this problem.
>
> If you are not for this plan and/or you are a maintainer of one of the
> above mentioned packages, your response would be appreciated. We're running
> out of time to complete this in time for perl 5.26.
>
> Thanks,
> Todd Rinaldo
>
>

Re: Looking for prior art on conventions for dep-listing

[Olivier Mengué]

2016-03-01 21:43 GMT+01:00 Peter Rabbitson :

> Are there other things out there targeting the same problem-domain? Is
> there something approaching a "cross-tooling convention" ?
>
>
>
cpanfile-dump

https://metacpan.org/pod/distribution/Module-CPANfile/script/cpanfile-dump

Re: Response to Rik's "Credit the first uploader" post

[Olivier Mengué]

> When it is a problem -- when the last uploader doesn't want to be the
point of contact -- under what circumstances is having someone else be
better?
>
> * if primary maintainer is active, they can re-release to be the "last
uploader"
> * if primary maintainer is not active, how is listing them any better for
the community than the last person? It's still a dead end.

If the primary maintainer is not active but is bothered for being contacted
about this old module he abandonned to his co-maints, he could just give up
his first-come permission to one of those co-maint.

I think that the point of exposing permissions more proheminently on
MetaCPAN is to push for some mouvement of those permissions to give them to
more active people (or to pseudo-people (ADOPTME) to clearly show
inactivity).

Oliver.

PS: the current permissions on a distribution are already exposed through
UI on rt.cpan.org, above the bug list of the dist.

2016-02-16 6:04 GMT+01:00 David Golden :

> This is my braindump response to
> https://rjbs.manxome.org/rubric/entry/2096
>
> I'm not clear on what real problems this is really intended to solve, and
> for at least some of the proposed problems, I'm not convinced it's the
> most-effective solution.
>
> I'll try to restate the problems in my own words:
>
> (1) Last uploader as "point of contact"
>
> How often is this really a problem? (e.g emails to point of contact) I
> suspect that most "contact" is via RT or GH issue trackers.  At least RT is
> multi-user.  (GH has its own issues).
>
> When it is a problem -- when the last uploader doesn't want to be the
> point of contact -- under what circumstances is having someone else be
> better?
>
> * if primary maintainer is active, they can re-release to be the "last
> uploader"
> * if primary maintainer is not active, how is listing them any better for
> the community than the last person?  It's still a dead end.
>
> (2) co-maint escape hatch
>
> Changing how metacpan lists stuff doesn't solve the underlying permissions
> problem, so I don't see how this is anything other than the same as #1.
>
> If we have co-maints without *any* primary maintainer, that's a problem
> with a one-time solution -- find them and promote them.  Then they can
> choose to handoff to ADOPTME or whatever.  (N.B. this is a good QAH project)
>
> If we have co-maints with inactive primaries, PAUSE admins are happy to
> help, which solves the actual problem instead of just hiding it on
> metacpan.  I suspect the number of times this is an issue is single-digits
> per year or less, so getting people willing to come forward is a matter of
> education.
>
> We still have the interesting situation of a co-maint who drops
> permissions, but still shows up as the uploader (from when they had
> permissions).  That's a detectable situation if we wanted to do something
> about it and I'll come back to that.
>
> We also have the interesting situation where all permissions on a package
> are dropped entirely and the next uploader gets first-come.  I think that's
> a bad idea -- if a permission drop would eliminate all owners, I think it
> should revert to ADOPTME, so that PAUSE can ensure a suitable handoff based
> on the CPAN river position.  (This too be a great QAH change, btw)
>
> ***
>
> Therefore, I don't think the proposal does much for the real problems
> underlying the stated problems.  That said, I can think of other reasons
> that such a change might be beneficial:
>
> (a) We now have the notion of a "primary" owner of a *distribution*, now
> that we manage distribution names via package permissions
>
> (b) We *already* have an "organization" view -- the primary plus
> co-maintainers
>
> (c) By listing *current* primary and co-maints for a distribution on
> MetaCPAN (based on matching package permission), we make ownership
> issues/depth more transparent to the community -- shifting the focus to
> those individuals rather than (historical) uploaders.
>
> This way, if a co-maint drops permissions, the visible "team" gets smaller.
>
> Another UX idea could be to annotate somehow how active each team member
> is on CPAN (not just for the distribution in question).  E.g. mouse over a
> team-member's picture and you get a pop-up that says "last seen X days ago"
> (i.e. last upload of anything to CPAN was X days ago).
>
> That lets the community see how active/passive the organization's members
> are.  When an active co-maint drops off, leaving the primary person who
> hasn't uploaded to CPAN in 8 years, that's significant and useful
> information to know.
>
> It's also excellent for highlighting ADOPTME, etc. situations.
>
> Thus, compared to Rik's original proposal, I suggest that emphasizing the
> full, current 06perms team (denoting who is primary/secondary and with some
> sort of "CPAN activity" indicator), is more beneficial than just
> emphasizing the primary maintainer over last uploader.
>
> I think it offers more useful community info about the 

Re: democratizing some of my dists

[Olivier Mengué]

2015-11-14 1:59 GMT+01:00 Ricardo Signes <perl.cpanw...@rjbs.manxome.org>:

> * Kent Fredric <kentfred...@gmail.com> [2015-11-13T19:00:36]
> > On 14 November 2015 at 12:50, James E Keenan <jk...@verizon.net> wrote:
> > > doesn't that mean that its ownership is already democratized?
> >
> > Not fully until he gives somebody else publish bits.
>
> In democracies, not every citizen can send the army to war.
>
>
Well, in the current times, some are tempted to call a few "citizens" of a
pseudo country an army bringing a war.


Olivier Mengué, from Paris.

Re: TRIAL dists shipping today

[Olivier Mengué]

2015-05-20 1:55 GMT+02:00 James E Keenan jk...@verizon.net:

 On 05/19/2015 10:51 AM, David Golden wrote:

 I have tuits today to ship my various TRIAL dists and keep an eye on them.
 Ideally, I wouldn't do them all in close succession, but my tuit supply is
 lumpy.


 I must have missed some discussion thread.  What is a TRIAL dist?


This is not something new.

Just a typo. The right term was TRIAL *release*, not *dist*.

Re: File::ShareDir - Outstanding modernization

[Olivier Mengué]

Hi,

Is it really necessary to introduce those new features (bloat?) in the
existing File::ShareDir ?

Why not just fork and keep the original File::ShareDir light?
What problems would be solved if the new features you plan were added to
the existing File::ShareDir? Which existing application would benefit from
these change just by upgrading to that new File::ShareDir, without using
the new APIs?

Olivier.

2015-05-04 16:34 GMT+02:00 Jens Rehsack rehs...@gmail.com:

 Hi,

 initially planned being one big topic for my QAH attendance, but Murphy
 decided to keep me busy otherwise (broken car, for everyone who didn't
 recognize on QAH...).

 Well - things are settling meanwhile and I have a few moments to think
 about the tasks I missed to finish in Berlin. One is File::ShareDir.

 The intension is to let File::ShareDir get closer to File::ConfigDir
 (and later let File::ConfigDir steal some features from File::ShareDir).

 The longterm goal is having it behave a bit more like share is intended
 (read until end of mail - don't scream here). There is no plan to break
 backwards compatibility (and if it happens on accident, the intension is
 to fix it and hopefully detect before it happens).

 Back to ideas for File::ShareDir:

 1) analogous to File::ConfigDir have a bunch of share-dir prefixes
including existing prefixes (core_share_dir, site_share_dir,
vendor_share_dir, ...) and new ones (system_share_dir,
 machine_share_dir,
here_share_dir, ...).
== here is can be sane to have plugins like
 https://metacpan.org/release/File-ConfigDir-Plack
for $ENV based locations (eg. FOO_BASE) or framework related
 extension.
 2) Upon the prefixes, the dist_dir(), module_dir() will calculate the
Full Qualified Share Dir as requested. It'll very likely to have other
preferences is prefix picking for legacy API and new API (- 3)
 3) introduce better accessors (dist_share_dir, module_share_dir,
 app_share_dir,
dist_config_dir, module_config_dir, ...).

 The goal is allow a module access share-dirs from different applications
 (eg. templates to process) or let applications rely on different immutable
 files from several distributions (think LaTeX as an example).

 Cheers
 --
 Jens Rehsack - rehs...@gmail.com