Re: Confirming PAUSE operating model safe harbor for Alt::* distributions
[email protected] (David Golden) Wed, 1 Nov 2017 13:55:58 -0400
| Newsgroups | perl.cpan.workers |
|---|---|
| Message-ID | <CAOeq1c8Fi5jGbtCoRF-wVLU4UG4fBSgNVLngY2LE2PC7r3_zNA@mail.gmail.com> |
--001a1147790e5271c4055cef977c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 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 particula= r > > environment variable like "PERL_ALLOW_ALT_MODULES=3D1" 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 thin= k > > 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 <[email protected]> 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 thi= s > 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' =3D> '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 i= s > 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 *us= e* > 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 syste= ms > 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 <[email protected]> wrote: > >> On 31 October 2017 at 05:39, Kent Fredric <[email protected]> wrote: >> > >> > On 31 October 2017 at 15:54, David Golden <[email protected]> wrote: >> > > On Mon, Oct 30, 2017 at 3:11 AM, Aristotle Pagaltzis < >> [email protected]> >> > > wrote: >> > >> >> > >> > - Per the "explicit user confirmation", I think an explicit >> opt-in >> > >> > must be present, not merely checking for overwriting via >> hashing. >> > >> >> > >> I don=E2=80=99t think so, and think it=E2=80=99s fine to not requir= e it. But you >> didn=E2=80=99t >> > >> state a reason why you think that so I don=E2=80=99t 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 <[email protected]> Twitter/IRC/GitHub: @xdg > --=20 David Golden <[email protected]> Twitter/IRC/GitHub: @xdg --001a1147790e5271c4055cef977c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">I asked on the private PAUSE admin list for other admins t= o add their opinion.=C2=A0 A couple replied privately on that list or don&#= 39;t subscribe to CPAN workers. I have their permission to repost their com= ments here:<br><br>From Steffen Mueller:<br>> I just read the cpan worke= rs thread. My stance on this was very well<br>> articulated by David'= ;s message at<br>><br>> <a href=3D"https://www.nntp.perl.org/group/pe= rl.cpan.workers/2017/10/msg1581.html">https://www.nntp.perl.org/group/perl.= cpan.workers/2017/10/msg1581.html</a><br>><br>> Maybe I feel a tad mo= re strongly. I think overwriting other<br>> distribution's files on = the file system is a very heavy-handed solution<br>> to a more general p= roblem (multi-versioning where not all versions are<br>> controlled by t= he same author, here with the limitation of only allowing<br>> one at a = time). Next to all the corner cases already pointed out, I<br>> think th= ere will be lots more that will particularly bite the less<br>> experien= ced users and sysadmins. The cost here outweighs the benefit by<br>> a m= ile.<br>><br>> As PAUSE admins with a published operating model, I th= ink we should be<br>> clear in that with explicit and specific user cons= ent, this behavior is<br>> technically acceptable, but from a point of v= iew of a group of people<br>> who've seen a lot of bad solutions, we= should nonetheless discourage<br>> that choice of solution.<br>><br>= > I'm not currently subscribed to cpan workers and don't have an= nntp<br>> client handy, so thus here. But you're all more than welc= ome to quote me<br>> with the above.<br><br>From Ron Savage:<br>> Fro= m David's post (copied into here, hence wrap) with replies in situ:<br>= > >My personal thoughts:<br>> > - The reason for the safe harbo= r clause in the first place was to allow<br>> > this sort of thing wh= ile putting appropriate protections in place for end<br>> > users -- = so I think the intent is clearly protected by the safe harbor and<br>> &= gt; questions should focus only on mechanisms and transparency.<br>><br>= > Agreed.<br>><br>> > - Per the "explicit user confirmatio= n", I think an explicit opt-in must<br>> > be present, not merel= y checking for overwriting via hashing.=C2=A0 If prompting<br>> > dur= ing Makefile.PL, I would prefer the default to be "no", but I don= 't<br>><br>> Agreed.<br>><br>> > think the safe harbor i= s violated if the default is "yes" (people who<br>> > auto-= accept prompts get what they deserve).<br>><br>> > - I would prefe= r checking for the presence of an environment variable<br>> > over pr= ompting as that similarly indicates explicit confirmation and is<br>> &g= t; kinder to many poor users who auto-accept prompts -- or whose cpan clien= t<br>> > does so on their behalf.<br>><br>> Agreed.<br>><br>= > > - I'd be happy to see a convention established checking for a= particular<br>> > environment variable like "PERL_ALLOW_ALT_MOD= ULES=3D1" that could apply<br>> > across many Alt-style modules.= =C2=A0 A Makefile.PL prompt could default to "yes"<br>> > i= f the environment variable is true..<br>><br>> Agreed.<br>><br>>= ; > - I have no objection to "DBIx::Class::Boring" as a name.= =C2=A0 I don't think<br>> > we should mandate a convention of &qu= ot;Alt::*".<br>><br>> It would help of the Alt name chosen clear= ly indicated the target name,<br>> to make searching MetaCPAN less painf= ul.<br><br><br></div><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Tue, Oct 31, 2017 at 9:33 AM, David Golden <span dir=3D"ltr"><<a = href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>></span> wrot= e:<br><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-l= eft:1px #ccc solid;padding-left:1ex"><div dir=3D"ltr"><div><div><div><div><= div><div><div><div>Let me be very clear that, to me, the issue at stake is = about two (or more) distributions "fighting" over a particular pa= th on the filesystem.=C2=A0 My position -- consistent with that of the Oper= ating Model -- is that this is not acceptable unless a user explicitly opts= into such a situation in some way.=C2=A0 Period.<br><br></div>There are ot= her alt-module mechanisms that don't have that problem.<br><br></div>Co= nsider a Bar and Alt::Bar that install into their usual places in the files= ystem.=C2=A0 Imagine a pragma "<a href=3D"http://shadowing.pm" target= =3D"_blank">shadowing.pm</a>" such that "use shadowing 'Bar&#= 39; =3D> 'Alt::Bar'" installs an @INC hook to replace the &= quot;Bar" prefix with "Alt::Bar".=C2=A0 I'd have no prob= lem with such a runtime effect because Bar is still usable in it's ordi= nary form by anything that doesn't invoke the shadowing.</div><div><br>= </div><div>I'd even be OK with a deep dependency invoking the shadowing= -- a deep dependency could do anything, after all, and users are responsib= le for their full dependency tree (even if, in practice, people don't p= ay attention).<br><br></div>From there, it's not hard to imagine that l= oading Alt::Bar *itself* does the shadowing, so that any subsequent loads o= f Bar::* are redirected to Alt::Bar::*.=C2=A0 As Bar is still usable indepe= ndently, that doesn't run into the Operating Model prohibition.<br></di= v><div><br></div><div>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].=C2=A0 Merel= y *installing* Alt::Bar does not change the loading of Bar.=C2=A0 The *use*= of Alt::Bar does, but the Operating Model doesn't speak to that (nor d= o I think it should).<br></div><div><br></div>There are other runtime mecha= nisms one could imagine along these lines.=C2=A0 E.g. loading Alt::Bar coul= d set $INC{"Bar.pm"}.=C2=A0 The design of such systems is left as= an exercise for the reader.=C2=A0 :-)<br><br></div>I'm curious what ot= her PAUSE admins think, and I'm not telling Peter what he has to do -- = only putting forward my view as one PAUSE admin.=C2=A0 In summary:<br><br><= /div>* To qualify for the "safe harbor" protection when overwriti= ng another indexed distributions files, I think an explicit user action to = opt in is a requirement<br></div>* I would prefer to see different approach= es for Alt-* modules that don't involve battling over the filesystem in= the first place<span class=3D"HOEnZb"><font color=3D"#888888"><br><br></fo= nt></span></div><span class=3D"HOEnZb"><font color=3D"#888888">David<br>=C2= =A0<br></font></span></div><div class=3D"gmail_extra"><div><div class=3D"h5= "><br><div class=3D"gmail_quote">On Tue, Oct 31, 2017 at 5:40 AM, Sawyer X = <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"_blan= k">[email protected]</a>></span> wrote:<br><blockquote class=3D"gmail_q= uote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1e= x"><div class=3D"m_-5086336978873001477HOEnZb"><div class=3D"m_-50863369788= 73001477h5">On 31 October 2017 at 05:39, Kent Fredric <<a href=3D"mailto= :[email protected]" target=3D"_blank">[email protected]</a>> wro= te:<br> ><br> > On 31 October 2017 at 15:54, David Golden <<a href=3D"mailto:xdg@xd= g.me" target=3D"_blank">[email protected]</a>> wrote:<br> > > On Mon, Oct 30, 2017 at 3:11 AM, Aristotle Pagaltzis <<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>><br> > > wrote:<br> > >><br> > >> >=C2=A0 =C2=A0 - Per the "explicit user confirmation&= quot;, I think an explicit opt-in<br> > >> >=C2=A0 =C2=A0 =C2=A0 must be present, not merely checking= for overwriting via hashing.<br> > >><br> > >> I don=E2=80=99t think so, and think it=E2=80=99s fine to not = require it. But you didn=E2=80=99t<br> > >> state a reason why you think that so I don=E2=80=99t know whe= ther I disagree<br> > >> with you.<br> > ><br> > ><br> > > Even if Peter's mechanism is in the spirit of the operating m= odel, I would<br> > > prefer the higher standard of "explicit confirmation" a= s the operating model<br> > > call for.<br> > ><br> > > If you need a rationale -- practically speaking -- consider this = scenario:<br> > ><br> > > 1. User without DBIC or DBIC::Boring installs some module Foo tha= t depends<br> > > on DBIC::Boring; DBIC::Boring gets silently installed.<br> > > 2. User installs some module Bar that depends on DBIC; because DB= IC doesn't<br> > > check for conflicts with DBIC::Boring, it silently overwrites it.= <br> > > 3. Foo is now broken.=C2=A0 User doesn't know why.<br> > ><br> > > Whereas if in #1, the user had to opt into DBIC::Boring, then the= y would be<br> > > accepting the risk of future breakage from DBIC conflicts.<br> ><br> > I would expect based on the stability goals of DBIC::Boring, that this= <br> > would mean the same kinds of breakages would be present for anyone who= <br> > simply upgraded from an older version of DBIC to a newer version of<br= > > DBIC<br> ><br> > And subsequently, that module Foo is broken with new version of DBIC *= anyway*<br> ><br> > Which means there is a logical problem in the ecosystem entirely<br> > independent of the existence of DBIC::Boring<br> <br> <br> </div></div>I disagree for several reasons.<br> <br> Firstly, you *assume* that due to DBIC::Boring's goals, DBIC will<br> break by upgrading. DBIC might break future versions and might not.<br> This is an assumption on your behalf and ignored the problem itself.<br> <br> Additionally, this assumes that DBIC::Boring's goals (even if pursued<b= r> wholeheartedly and contain absolutely zero mistakes) would be the aim<br> (and success) of any other Alt::*, thus dismissing David's general<br> point, beyond DBIC::Boring.<br> <br> David gave a plausible situation in which package Foo could break due<br> to unknowingly depending on Alt::Bar instead of Bar, wherein Bar might<br> overwrite Alt::Bar. If you keep your position and assumptions on DBIC<br> or DBIC::Boring aside, this problem is quite clear. There is an<br> inherent problem for a user that does not explicitly know every<br> distribution in their application's chain of dependencies.<br> <br> Honestly, the only ways I can think of (off-hand) is either 1)<br> explicitly indicating "Yup, I know this. I'm okay with it. I'l= l take<br> care of it if it breaks," or 2) A mechanism that detects it and<br> reinstates Alt::Bar at the end; or 3) Bar knowing about Alt::Bar (and<br> Alt::Bar::ButBetter) and not overwrite them. The last is unlikely, the<br> first is more straightforward, and the second a long-term (but perhaps<br> fragile) possibility.<br> <br> You cannot dismiss this case, only figure out how to ease it.<br> </blockquote></div><br><br clear=3D"all"><br></div></div><span class=3D"">-= - <br><div class=3D"m_-5086336978873001477gmail_signature" data-smartmail= =3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr"><div>David Gold= en <<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]</a>> T= witter/IRC/GitHub: @xdg</div></div></div></div></div> </span></div> </blockquote></div><br><br clear=3D"all"><br>-- <br><div class=3D"gmail_sig= nature" data-smartmail=3D"gmail_signature"><div dir=3D"ltr"><div><div dir= =3D"ltr"><div>David Golden <<a href=3D"mailto:[email protected]" target=3D"_bla= nk">[email protected]</a>> Twitter/IRC/GitHub: @xdg</div></div></div></div></di= v> </div> --001a1147790e5271c4055cef977c--