Re: Confirming PAUSE operating model safe harbor for Alt::* distributions
[email protected] (David Golden) Tue, 31 Oct 2017 09:33:38 -0400
| Newsgroups | perl.cpan.workers |
|---|---|
| Message-ID | <CAOeq1c_1-dLEYdZK+b3Cc_-L7DFpNeHZNn91ZviZ5QmC31xhhQ@mail.gmail.com> |
--089e082fd1a0432417055cd7cff5
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
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'
=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 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 <[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]=
e
> >
> > > 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 require=
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 operatin=
g
> 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.
>
--=20
David Golden <[email protected]> Twitter/IRC/GitHub: @xdg
--089e082fd1a0432417055cd7cff5
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
<div dir=3D"ltr"><div><div><div><div><div><div><div><div>Let me be very cle=
ar that, to me, the issue at stake is about two (or more) distributions &qu=
ot;fighting" over a particular path on the filesystem.=C2=A0 My positi=
on -- consistent with that of the Operating Model -- is that this is not ac=
ceptable unless a user explicitly opts into such a situation in some way.=
=C2=A0 Period.<br><br></div>There are other alt-module mechanisms that don&=
#39;t have that problem.<br><br></div>Consider a Bar and Alt::Bar that inst=
all into their usual places in the filesystem.=C2=A0 Imagine a pragma "=
;<a href=3D"http://shadowing.pm">shadowing.pm</a>" such that "use=
shadowing 'Bar' =3D> 'Alt::Bar'" installs an @INC =
hook to replace the "Bar" prefix with "Alt::Bar".=C2=A0=
I'd have no problem with such a runtime effect because Bar is still us=
able in it's ordinary form by anything that doesn't invoke the shad=
owing.</div><div><br></div><div>I'd even be OK with a deep dependency i=
nvoking the shadowing -- a deep dependency could do anything, after all, an=
d users are responsible for their full dependency tree (even if, in practic=
e, people don't pay attention).<br><br></div>From there, it's not h=
ard to imagine that loading Alt::Bar *itself* does the shadowing, so that a=
ny subsequent loads of Bar::* are redirected to Alt::Bar::*.=C2=A0 As Bar i=
s still usable independently, that doesn't run into the Operating Model=
prohibition.<br></div><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<br><br></div>David<br>=C2=A0<br></div><div class=3D"gmail_=
extra"><br><div class=3D"gmail_quote">On Tue, Oct 31, 2017 at 5:40 AM, Sawy=
er X <span dir=3D"ltr"><<a href=3D"mailto:[email protected]" target=3D"=
_blank">[email protected]</a>></span> wrote:<br><blockquote class=3D"gm=
ail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-le=
ft:1ex"><div class=3D"HOEnZb"><div class=3D"h5">On 31 October 2017 at 05:39=
, Kent Fredric <<a href=3D"mailto:[email protected]">kentfredric@gma=
il.com</a>> wrote:<br>
><br>
> On 31 October 2017 at 15:54, David Golden <<a href=3D"mailto:xdg@xd=
g.me">[email protected]</a>> wrote:<br>
> > On Mon, Oct 30, 2017 at 3:11 AM, Aristotle Pagaltzis <<a href=
=3D"mailto:[email protected]">[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>-- <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>
--089e082fd1a0432417055cd7cff5--