Re: Confirming PAUSE operating model safe harbor for Alt::* distributions

--001a1147790e6a73b4055ccee27d
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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 require it. =
But you didn=E2=80=99t
> state a reason why you think that so I don=E2=80=99t know whether I disag=
ree
> 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.

Further, while I trust Peter to be sufficiently clever and user-considerate
in his Alt-style design, I don't want the lead-off precedent to depend on
cleverness because I don't trust anyone modeling their work on Peter's will
exercise the same level of care and diligence.


> Such
> a requirement would therefore mean that users who intend to stay on
> the DBIx::Class::Boring fork, or who use a downstream project that has
> chosen the DBIx::Class::Boring fork, will forever be needing to shim the
> setting of this environment variable into their toolchain or deploy
> machinery.
>
>
I believe that is a feature, not a bug.  Among other things, such an
environment variable will show up in "perl -V" output, CPAN Testers reports
and analytics, etc. which might help diagnose any unexpected complications
from using Alt-style modules.

David


--=20
David Golden <[email protected]> Twitter/IRC/GitHub: @xdg

--001a1147790e6a73b4055ccee27d
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">On Mon, Oct 30, 2017 at 3:11 AM, Aristotle Pagaltzis <span=
 dir=3D"ltr">&lt;<a href=3D"mailto:[email protected]" target=3D"_blank">paga=
[email protected]</a>&gt;</span> wrote:<br><div class=3D"gmail_extra"><div class=
=3D"gmail_quote"><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8=
ex;border-left:1px #ccc solid;padding-left:1ex">&gt;=C2=A0 =C2=A0 - Per the=
 &quot;explicit user confirmation&quot;, I think an explicit opt-in<br>
<span class=3D"">&gt;=C2=A0 =C2=A0 =C2=A0 must be present, not merely check=
ing for overwriting via hashing.<br>
<br>
</span>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 whether I disagre=
e<br>
with you.<br></blockquote><div><br></div><div>Even if Peter&#39;s mechanism=
 is in the spirit of the operating model, I would prefer the higher standar=
d of &quot;explicit confirmation&quot; as the operating model call for.</di=
v><div><br></div><div>If you need a rationale -- practically speaking -- co=
nsider this scenario:</div><div><br></div><div>1. User without DBIC or DBIC=
::Boring installs some module Foo that depends on DBIC::Boring; DBIC::Borin=
g gets silently installed.<br></div><div>2. User installs some module Bar t=
hat depends on DBIC; because DBIC doesn&#39;t check for conflicts with DBIC=
::Boring, it silently overwrites it.</div><div>3. Foo is now broken.=C2=A0 =
User doesn&#39;t know why.</div><div><br></div><div>Whereas if in #1, the u=
ser had to opt into DBIC::Boring, then they would be accepting the risk of =
future breakage from DBIC conflicts.</div><div><br></div><div>Further, whil=
e I trust Peter to be sufficiently clever and user-considerate in his Alt-s=
tyle design, I don&#39;t want the lead-off precedent to depend on clevernes=
s because I don&#39;t trust anyone modeling their work on Peter&#39;s will =
exercise the same level of care and diligence.<br></div><div>=C2=A0</div><b=
lockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px =
#ccc solid;padding-left:1ex">Such<br>
a requirement would therefore mean that users who intend to stay on<br>
the DBIx::Class::Boring fork, or who use a downstream project that has<br>
chosen the DBIx::Class::Boring fork, will forever be needing to shim the<br=
>
setting of this environment variable into their toolchain or deploy<br>
machinery.<br>
<br></blockquote><div><br></div><div>I believe that is a feature, not a bug=
.=C2=A0 Among other things, such an environment variable will show up in &q=
uot;perl -V&quot; output, CPAN Testers reports and analytics, etc. which mi=
ght help diagnose any unexpected complications from using Alt-style modules=
.<br></div><div>=C2=A0</div>David<br></div><br clear=3D"all"><br>-- <br><di=
v class=3D"gmail_signature" data-smartmail=3D"gmail_signature"><div dir=3D"=
ltr"><div><div dir=3D"ltr"><div>David Golden &lt;<a href=3D"mailto:xdg@xdg.=
me" target=3D"_blank">[email protected]</a>&gt; Twitter/IRC/GitHub: @xdg</div></di=
v></div></div></div>
</div></div>

--001a1147790e6a73b4055ccee27d--