Re: Confirming PAUSE operating model safe harbor for Alt::* distributions
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 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 parag
Re: Confirming PAUSE operating model safe harbor for Alt::* distributions
On Wed, 01 Nov 2017 00:44:12 +0100, Andreas Koenig 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
Re: Confirming PAUSE operating model safe harbor for Alt::* distributions
I asked on the private PAUSE admin list for other admins to add their
opinion. A couple replied privately on that list or don't subscribe to
CPAN workers. I have their permission to repost their comments here:
>From Steffen Mueller:
> I just read the cpan workers thread. My stance on this was very well
> articulated by David's message at
>
> https://www.nntp.perl.org/group/perl.cpan.workers/2017/10/msg1581.html
>
> Maybe I feel a tad more strongly. I think overwriting other
> distribution's files on the file system is a very heavy-handed solution
> to a more general problem (multi-versioning where not all versions are
> controlled by the same author, here with the limitation of only allowing
> one at a time). Next to all the corner cases already pointed out, I
> think there will be lots more that will particularly bite the less
> experienced users and sysadmins. The cost here outweighs the benefit by
> a mile.
>
> As PAUSE admins with a published operating model, I think we should be
> clear in that with explicit and specific user consent, this behavior is
> technically acceptable, but from a point of view of a group of people
> who've seen a lot of bad solutions, we should nonetheless discourage
> that choice of solution.
>
> I'm not currently subscribed to cpan workers and don't have an nntp
> client handy, so thus here. But you're all more than welcome to quote me
> with the above.
>From Ron Savage:
> From David's post (copied into here, hence wrap) with replies in situ:
> >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. If
prompting
> > during Makefile.PL, I would prefer the default to be "no", but I don't
>
> Agreed.
>
> > think the safe harbor is violated if the default is "yes" (people who
> > auto-accept prompts get what they deserve).
>
> > - 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.
>
> Agreed.
>
> > - 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..
>
> Agreed.
>
> > - I have no objection to "DBIx::Class::Boring" as a name. I don't think
> > we should mandate a convention of "Alt::*".
>
> It would help of the Alt name chosen clearly indicated the target name,
> to make searching MetaCPAN less painful.
On Tue, Oct 31, 2017 at 9:33 AM, David Golden wrote:
> 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
Re: Confirming PAUSE operating model safe harbor for Alt::* distributions
FWIW I agree with Andreas on every point. There’s a big difference between 1) “use Foo::XS” will install hooks into the Foo namespace for the XS optimized implementation of Foo and 2) “cpam Foo::Bar” will overwrite site_lib/…/Foo.pm Manipulating namespace in memory seems … Perl-ish (and appropriate-ish; and at least the signed up for it explicitly in the code). Having the installer write different things to disk than expected seems outright dangerous. As Andreas said, the pitfalls are many (too many in my opinion). Reliably managing and upgrading Perl installations for production environments is already plenty complex, I don’t think we should make it worse. Ask
Re: Press inquiry from WIRED: What happens to open source projects when their maintainers pass away?
> From: Klint Finley mailto:klintfin...@gmail.com>> > Date: Tue, Oct 17, 2017 at 10:07 PM > Subject: Press inquiry from WIRED: What happens to open source projects when > their maintainers pass away? > To: > > > Hi, I'm a reporter for Wired.com and I'm working on a story about the > afterlife of open source projects after their maintainers pass away. > > In many cases, open source projects are owned by foundations that can > handle a transition. […] I just spent about 45 minutes on the phone with Klint, talking through CPAN, PAUSE, and how we handle situations where the original author / current maintainer is no longer responsive, or has retired, or passed away. Most of the questions he asked are explicitly addressed in the PAUSE Operating Model, so the timing was good :-) Neil
