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
