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

[Kent Fredric]

On 31 October 2017 at 15:54, David Golden  wrote:
> On Mon, Oct 30, 2017 at 3:11 AM, Aristotle Pagaltzis 
> 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

The only thing DBIC::Boring adds to this table is a situation where
Foo is not broken, other than "Have old DBIC"

Complaining that DBIC::Boring's own sub-ecosystem could become broken
by DBIC::Boring existing seems strange here, because the goal of this
safe-harbour provision is that DBIC::Boring can be permitted to exist
without interfering with DBIC's ecosystem.

And nothing in that example suggests DBIC::Boring interferes with
DBIC's ecosystem.

Only that DBIC's ecosystem may retroactively interfere with
DBIC::Boring's, which is an understood consequence of that design.


-- 
Kent

KENTNL - https://metacpan.org/author/KENTNL

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

[Aristotle Pagaltzis]

* David Golden  [2017-10-26 14:58]:
> What do we think about this? Do we feel it falls under the 'safe
> harbor' exception?

As far as I can see, the mechanism described by Peter does not permit
scenarios in which a user unwittingly gets their Perl installation
screwed over by DBIx::Class::Boring. As such, it seems to me that the
mechanism follows the spirit of the principles, and therefore should
clearly fall under the safe-harbour clause in question.

> 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.

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.

In particular, requiring an opt-in even in presence of a hash match
interacts badly with the fact that the actual codebase in the fork will
be staying in the DBIx::Class namespace for at least a very long time,
because it means that an opt-in is required not only for switching to
the fork, but also for all upgrades *after* following the fork. 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.

OTOH, I believe upgrading users of a forked module from a pre-fork
version to the post-fork codebase is fine *so long as* the fork has
a sufficiently strong backcompat commitment to pre-fork versions. And
as far as that applies to DBIx::Class::Boring, the most neutral way
I can express myself is that the entire situation came to a head because
Peter’s commitment to backcompat has been perceived as *too* overriding.

These are my reasons to believe that explicit opt-in under pure-upgrade
situations (as opposed to switching an installation over from the other
fork) is neither necessary nor reasonable under the mechanism described
in the proposal you quoted.

>  If prompting during Makefile.PL, I would prefer the default to be
>  "no", but I don't think the safe harbor is violated if the
>  default is "yes" (people who auto-accept prompts get what they
>  deserve).

The proposal you quoted says that the installation will *abort*, without
even a prompt, unless explicit opt-in via environment variable is given.
Therefore this requirement is fulfilled in spades.

>- 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.

(See right above.)

>- 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..

Generally, yes. But I have to agree with Chad on this point: an opt-in
should be specific to particular modules, and not limit the user to
expressing a blanket “I accept any Alt:: that might be listed anywhere
in my dep chain”. In fact I raised this exact issue a long time ago:
https://github.com/ingydotnet/alt-pm/issues/3

It’s fine for there to be a convention for such opt-ins. It’s possibly
even a good idea (if it comes up in enough different cases in practice
to matter).

Peter’s proposal in particular is already sane on that specific front.

>- I have no objection to "DBIx::Class::Boring" as a name. I don't
>  think we should mandate a convention of "Alt::*".

Agree. I believe that conveying intent through the name is imperative
only when the protection of users at install time is too weak – as it
has been in Ingy’s conception of the Alt:: concept.

Regards,
-- 
Aristotle Pagaltzis //