Re: Supporting a perl without . in @INC
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 :
> 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
2016-03-02 10:39 GMT+01:00 Peter Rabbitson : > The use case in question is that I am preparing to replace > Module::Install's `perl Makefile.PL && make listdeps` idiom with a > pure-EUMM-based "something else". I was looking for available prior art in order to converge on *naming*. > Given further searching and the replies in this thread, I am simply going > to recreate the 'listdep' target more-or-less-as-is. > > Is 'listdep' just a typo or will we really have both 'listdeps' and 'listdep'? > Thanks for the thoughts! > Cheers >
Re: Looking for prior art on conventions for dep-listing
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
> 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 "quality" of the > dis
Re: Response to Rik's "Credit the first uploader" post
Related discussions and opinions: https://github.com/CPAN-API/metacpan-web/issues/1643 http://neilb.org/2016/02/13/it-takes-a-community.html http://wollmers-perl.blogspot.co.at/2016/02/credit-first-or-last-uploader-on.html 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 "quality" of the > distribution and still allows a comaint to "drop off" if desired. > > I think the current "authors", "contributors" and "uploaders" can/should > be consolidated into a "contributors" list, orthogonal to the > primary+comaint team indication. (As there may be legacy authors in the > 'authors' metadata who don't have any current permission). > > I.e. the "contributors superset" is "everyone who ever worked on this > thing" whereas "primary+co-maint" is "current group taking responsibility > for this thing". > > *** > > Summary: > > * promote co-maints without primary to primary > * make last owner dropping permissions revert to ADOPTME > * publicize the PAUSE admin process to encourage co-maints to propose >
Re: democratizing some of my dists
2015-11-14 1:59 GMT+01:00 Ricardo Signes : > * Kent Fredric [2015-11-13T19:00:36] > > On 14 November 2015 at 12:50, James E Keenan 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
2015-05-20 1:55 GMT+02:00 James E Keenan : > 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
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 : > 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 > >
