I asked on the private PAUSE admin list for other admins to add their opinion. A couple replied privately on that list or don't subscribe to CPAN workers. I have their permission to repost their comments here:
>From Steffen Mueller: > I just read the cpan workers thread. My stance on this was very well > articulated by David's message at > > https://www.nntp.perl.org/group/perl.cpan.workers/2017/10/msg1581.html > > Maybe I feel a tad more strongly. I think overwriting other > distribution's files on the file system is a very heavy-handed solution > to a more general problem (multi-versioning where not all versions are > controlled by the same author, here with the limitation of only allowing > one at a time). Next to all the corner cases already pointed out, I > think there will be lots more that will particularly bite the less > experienced users and sysadmins. The cost here outweighs the benefit by > a mile. > > As PAUSE admins with a published operating model, I think we should be > clear in that with explicit and specific user consent, this behavior is > technically acceptable, but from a point of view of a group of people > who've seen a lot of bad solutions, we should nonetheless discourage > that choice of solution. > > I'm not currently subscribed to cpan workers and don't have an nntp > client handy, so thus here. But you're all more than welcome to quote me > with the above. >From Ron Savage: > From David's post (copied into here, hence wrap) with replies in situ: > >My personal thoughts: > > - The reason for the safe harbor clause in the first place was to allow > > this sort of thing while putting appropriate protections in place for end > > users -- so I think the intent is clearly protected by the safe harbor and > > questions should focus only on mechanisms and transparency. > > Agreed. > > > - Per the "explicit user confirmation", I think an explicit opt-in must > > be present, not merely checking for overwriting via hashing. If prompting > > during Makefile.PL, I would prefer the default to be "no", but I don't > > Agreed. > > > think the safe harbor is violated if the default is "yes" (people who > > auto-accept prompts get what they deserve). > > > - I would prefer checking for the presence of an environment variable > > over prompting as that similarly indicates explicit confirmation and is > > kinder to many poor users who auto-accept prompts -- or whose cpan client > > does so on their behalf. > > Agreed. > > > - I'd be happy to see a convention established checking for a particular > > environment variable like "PERL_ALLOW_ALT_MODULES=1" that could apply > > across many Alt-style modules. A Makefile.PL prompt could default to "yes" > > if the environment variable is true.. > > Agreed. > > > - I have no objection to "DBIx::Class::Boring" as a name. I don't think > > we should mandate a convention of "Alt::*". > > It would help of the Alt name chosen clearly indicated the target name, > to make searching MetaCPAN less painful. On Tue, Oct 31, 2017 at 9:33 AM, David Golden <x...@xdg.me> wrote: > Let me be very clear that, to me, the issue at stake is about two (or > more) distributions "fighting" over a particular path on the filesystem. > My position -- consistent with that of the Operating Model -- is that this > is not acceptable unless a user explicitly opts into such a situation in > some way. Period. > > There are other alt-module mechanisms that don't have that problem. > > Consider a Bar and Alt::Bar that install into their usual places in the > filesystem. Imagine a pragma "shadowing.pm" such that "use shadowing > 'Bar' => 'Alt::Bar'" installs an @INC hook to replace the "Bar" prefix with > "Alt::Bar". I'd have no problem with such a runtime effect because Bar is > still usable in it's ordinary form by anything that doesn't invoke the > shadowing. > > I'd even be OK with a deep dependency invoking the shadowing -- a deep > dependency could do anything, after all, and users are responsible for > their full dependency tree (even if, in practice, people don't pay > attention). > > From there, it's not hard to imagine that loading Alt::Bar *itself* does > the shadowing, so that any subsequent loads of Bar::* are redirected to > Alt::Bar::*. As Bar is still usable independently, that doesn't run into > the Operating Model prohibition. > > To justify why, recall that the prohibition is stated as "*installing* an > indexed distribution.. should not change post-install module loading for > any package that is not indexed to that distribution" [emphasis mine]. > Merely *installing* Alt::Bar does not change the loading of Bar. The *use* > of Alt::Bar does, but the Operating Model doesn't speak to that (nor do I > think it should). > > There are other runtime mechanisms one could imagine along these lines. > E.g. loading Alt::Bar could set $INC{"Bar.pm"}. The design of such systems > is left as an exercise for the reader. :-) > > I'm curious what other PAUSE admins think, and I'm not telling Peter what > he has to do -- only putting forward my view as one PAUSE admin. In > summary: > > * To qualify for the "safe harbor" protection when overwriting another > indexed distributions files, I think an explicit user action to opt in is a > requirement > * I would prefer to see different approaches for Alt-* modules that don't > involve battling over the filesystem in the first place > > David > > > On Tue, Oct 31, 2017 at 5:40 AM, Sawyer X <xsawy...@gmail.com> wrote: > >> On 31 October 2017 at 05:39, Kent Fredric <kentfred...@gmail.com> wrote: >> > >> > On 31 October 2017 at 15:54, David Golden <x...@xdg.me> wrote: >> > > On Mon, Oct 30, 2017 at 3:11 AM, Aristotle Pagaltzis < >> pagalt...@gmx.de> >> > > wrote: >> > >> >> > >> > - Per the "explicit user confirmation", I think an explicit >> opt-in >> > >> > must be present, not merely checking for overwriting via >> hashing. >> > >> >> > >> I don’t think so, and think it’s fine to not require it. But you >> didn’t >> > >> state a reason why you think that so I don’t know whether I disagree >> > >> with you. >> > > >> > > >> > > Even if Peter's mechanism is in the spirit of the operating model, I >> would >> > > prefer the higher standard of "explicit confirmation" as the >> operating model >> > > call for. >> > > >> > > If you need a rationale -- practically speaking -- consider this >> scenario: >> > > >> > > 1. User without DBIC or DBIC::Boring installs some module Foo that >> depends >> > > on DBIC::Boring; DBIC::Boring gets silently installed. >> > > 2. User installs some module Bar that depends on DBIC; because DBIC >> doesn't >> > > check for conflicts with DBIC::Boring, it silently overwrites it. >> > > 3. Foo is now broken. User doesn't know why. >> > > >> > > Whereas if in #1, the user had to opt into DBIC::Boring, then they >> would be >> > > accepting the risk of future breakage from DBIC conflicts. >> > >> > I would expect based on the stability goals of DBIC::Boring, that this >> > would mean the same kinds of breakages would be present for anyone who >> > simply upgraded from an older version of DBIC to a newer version of >> > DBIC >> > >> > And subsequently, that module Foo is broken with new version of DBIC >> *anyway* >> > >> > Which means there is a logical problem in the ecosystem entirely >> > independent of the existence of DBIC::Boring >> >> >> I disagree for several reasons. >> >> Firstly, you *assume* that due to DBIC::Boring's goals, DBIC will >> break by upgrading. DBIC might break future versions and might not. >> This is an assumption on your behalf and ignored the problem itself. >> >> Additionally, this assumes that DBIC::Boring's goals (even if pursued >> wholeheartedly and contain absolutely zero mistakes) would be the aim >> (and success) of any other Alt::*, thus dismissing David's general >> point, beyond DBIC::Boring. >> >> David gave a plausible situation in which package Foo could break due >> to unknowingly depending on Alt::Bar instead of Bar, wherein Bar might >> overwrite Alt::Bar. If you keep your position and assumptions on DBIC >> or DBIC::Boring aside, this problem is quite clear. There is an >> inherent problem for a user that does not explicitly know every >> distribution in their application's chain of dependencies. >> >> Honestly, the only ways I can think of (off-hand) is either 1) >> explicitly indicating "Yup, I know this. I'm okay with it. I'll take >> care of it if it breaks," or 2) A mechanism that detects it and >> reinstates Alt::Bar at the end; or 3) Bar knowing about Alt::Bar (and >> Alt::Bar::ButBetter) and not overwrite them. The last is unlikely, the >> first is more straightforward, and the second a long-term (but perhaps >> fragile) possibility. >> >> You cannot dismiss this case, only figure out how to ease it. >> > > > > -- > David Golden <x...@xdg.me> Twitter/IRC/GitHub: @xdg > -- David Golden <x...@xdg.me> Twitter/IRC/GitHub: @xdg
