On Wed, 01 Nov 2017 00:44:12 +0100, Andreas Koenig <andreas.koenig.7os6v...@franz.ak.mind.de> 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. > > 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. 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 > > 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. 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'ê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. > > [...] > > > 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. > -- 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/
pgp4j8PH933dV.pgp
Description: OpenPGP digital signature
