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

--Sig_/gc5APMkZQDC798y2eu5qrU_
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Wed, 01 Nov 2017 00:44:12 +0100, Andreas Koenig
<[email protected]> wrote:

> My reasoning tries to base on previous art first, the letter of the
> Pause Operating Model (POM) second, and the intent of the POM third.
> Since the intent can only be guessed, we would hope that we do not
> need to resort to that. But then there is a fourth thing: reasoning what
> we as a community *need* to achieve.
>=20
> Previous art
>=20
> One distribution comes to mind that asks the user whether he wants to
> install a secondary namespace:
>=20
>  : Installing Data::Dump::Streamer
>  :=20
>  : I can install a shortcut so you can use the package 'DDS'
>  : as though it was 'Data::Dump::Streamer'. This is handy for oneliners.
>  : *Note* that if you select 'no' below and you already
>  : have it installed then it will be removed.
>  :=20
>  : Would you like me to install the shortcut? (yes/no) [no ]
>=20
> So it is a long established practice, that modules may ask for
> permission to be installed under a different name. I haven't ever heard
> complaints about that.

Yes, I also see this as common practice

I only saw these as top-level "namespace", and none with ::

I have CSV.pm available for Text::CSV_XS adding Data::Peek, but the
build does not offer it as shortcut. You have to install it yourself
from the git checkout (it is not included in the release tarball)
https://github.com/Tux/Text-CSV_XS/blob/master/sandbox/CSV.pm

I have DP.pm for Data::Peek, just like DDS for Data::Dump::Streamer.
https://github.com/Tux/Data-Peek/blob/master/Makefile.PL#L35

> Letter of the POM
>=20
> The following citation is taken directly from the POM:
>=20
>  : * Installing your module(s) should not result in changes to
>  :   someone else's modules that might already be installed,
>  :   either by changing them or removing them.

Hmm, that would mean that DDS and DP should *ONLY* install if DP.pm or
DDS.pm does not exist or exists as the intended wrapper in a previous
version. (/me takes action ...)

>  : * The one exception to the above is where that's the whole raison d'=
=C3=AAtre
>  :   of your module.
>  :   In that case it should be clearly documented as such,
>  :   and the installation process should get explicit user confirmation
>  :   that they wish to proceed with this.
>  :   The documentation and name of your module should be respectful.
>=20
> I understand the first paragraph as: if your module is A you must not
> change or remove module B. The second paragraph makes this mandate
> relative: if your module is A you must not change or remove module B
> *under the hood*. But everything's fair if you predeclare. If all you
> want to achieve is changing B, then get explicit permission from the end
> user and do it.
>=20
> Intent of the POM
>=20
> This is my personal reading of the two written paragraphs I cited above,
> so probably the intent: Perl5 is really bad at dealing with two
> implementations on the same namespace, so if a precious namespace has
> competing interpretations and people cannot come up with a clever way of
> separating code into alternative namespaces, we should not get in the
> way as long as developer and end user agree on what they want to
> achieve.
>=20
> What *we* must achieve
>=20
> Foremost debuggability: if things go wrong we should be able to find out
> which parties were involved and how. What was intended, what happened,
> which contract or perceived contract was broken. And we need to be able
> to identify a way forward. We need a way to go from A to B and from B to
> A. When B has been overwritten, we need a way to find out whether the
> user has agreed to overwriting B.
>=20
> The overwriter is kindly asked to provide clue about what's going on and
> avoid obscuring things. For example, how will cpantesters reports look
> like? They should of course be attributed to the overwriting module, not
> to the overwritten one.
>=20
> After installation: in the past we could pretty much rely on paths in
> the filesystem and version numbers. This stops working when a distro
> could overwrite a file with code that declares the same version number.
> But I can imagine plenty of ways to prevent that sort of confusion. Some
> will *just work*, so we probably need not explain the nitty gritty
> details in the POM how this is achieved best. People will have to find
> that out on their own.
>=20
> And besides debuggability what we really need to achieve is that such
> approaches about dealing with conflicting goals find a way of
> coexistence. What we cannot allow is that module A's whole raison d'=C3=
=AAtre
> is modifying B and B's whole raison d'=C3=AAtre is modifying A. If such a
> circular reference happens, it's probably time to reboot CPAN.
>=20
> Yes, it should not be done lightly. It may cause major havoc if done
> wrongly. There are probably plenty of pitfalls before mutually each
> other overwriting CPAN modules.
>=20
>  [...] =20
>=20
>   > 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. =20
>=20
> Agreed. Onus of proof is with the overwriter. Whether the agreement must
> be renewed on every installation is subject to their agreement.
> Overwriter is kindly requested to be clear about the intent and how to
> opt out later.
>=20
>   > [...] =20
>=20
>   > 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). =20
>=20
> I believe, the paragraph about "The one exception" would justify the one
> exception where developer and end user agree to do something
> *exceptional*. I don't think it is a carte blanche to break CPAN but it
> could be a carte blanche to help CPAN to survive in times of trouble.
> Like all sharp tools, it has potential to be the rope to hang yourself.
>=20
>   > 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: =20
>=20
>   > * 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 =20
>=20
> Agreed.
>=20
>   > * I would prefer to see different approaches for Alt-* modules that
>   > don't involve battling over the filesystem in the first place =20
>=20
> Of course I agree here, but this ship has sailed. And I also think perl
> sometimes does not provide enough rope. At least I understood the
> sentence about "the one exception" as a way to prevent deadlock due to
> all sort of shortcomings in the real world.
>=20


--=20
H.Merijn Brand  http://tux.nl   Perl Monger  http://amsterdam.pm.org/
using perl5.00307 .. 5.27   porting perl5 on HP-UX, AIX, and openSUSE
http://mirrors.develooper.com/hpux/        http://www.test-smoke.org/
http://qa.perl.org   http://www.goldmark.org/jeff/stupid-disclaimers/

--Sig_/gc5APMkZQDC798y2eu5qrU_
Content-Type: application/pgp-signature
Content-Description: OpenPGP digital signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2

iQEcBAEBAgAGBQJZ+eQPAAoJEAOhR6E+XcCYrE0H/0zDHkmlGsAd1cLyJUyh/VnA
VY6U9lGJwuQ0YMm+IxwkKw52IYIBJWY5wvtEw7MTJdAEsErFIwD1oSJkjzhf/ufX
buDzGIItLs2nA3T7ql3JhfJP0ZpNZdXJfGaM9knZf6vxNlWc9yzieA+7+u9Su17B
LaRdgrJvIlFydpN/rDC9TfJOpswmWClNJEVwIi5y+mvZo8wJjqQD+CjEKcUS5mg3
ZTCqScSdR7pn6HAfNSO1ZBaSqPd4H74W7zKJMxSWBS6i/4K3b9Wwaji7YWoy9su9
Ia60xyQ1zyyW5JXSgLaBgzcjZTUVHT9+USRmhIsX1Tlu0hta5ETtCsOqa2ntfTU=
=USSl
-----END PGP SIGNATURE-----

--Sig_/gc5APMkZQDC798y2eu5qrU_--