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.
Previous art One distribution comes to mind that asks the user whether he wants to install a secondary namespace: : Installing Data::Dump::Streamer : : 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. : : Would you like me to install the shortcut? (yes/no) [no ] 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. Letter of the POM The following citation is taken directly from the POM: : * 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. : * The one exception to the above is where that's the whole raison d'être : 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. 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. Intent of the POM 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. What *we* must achieve 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. 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. 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. 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'être is modifying B and B's whole raison d'être is modifying A. If such a circular reference happens, it's probably time to reboot CPAN. 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. >>>>> On Tue, 31 Oct 2017 09:33:38 -0400, David Golden <x...@xdg.me> said: > 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. 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. > [...] > 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). 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. > 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 Agreed. > * I would prefer to see different approaches for Alt-* modules that > don't involve battling over the filesystem in the first place 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. -- andreas
