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

[Salve J Nilsen]

David Golden said:

On Thu, Oct 26, 2017 at 11:29 AM, Chad Granum  wrote:


I have a small objection to putting an alt module in a namespace other
than alt: It is less obvious. If I see Alt::Thing I will simply know it
will replace Thing.


Consider, too, if someone else wants to another alternative Thing.
Alt::Thing2 -- is that a second Alt::Thing?  Or an alternative of Thing2?

Possibly namespacing like Thing::Alt::Boring would then allow
Thing::Alt::Spiffy, etc.  But I don't want to have explicit rules about
this.  I think intent is more important.


Would adding a field to the META spec about API conformance solve some this?

api_conforms_to:
   module: CPAN::Thing
   version: 2.61


- Salve (possibly opening a can of worms here)

--
#!/usr/bin/env perl
sub AUTOLOAD{$AUTOLOAD=~/.*::(\d+)/;seek(DATA,$1,0);print# Salve Joshua Nilsen
getc DATA}$"="'};&{'";@_=unpack("C*",unpack("u*",':50,$'.#
'3!=0"59,6!`%%P\0!1)46%!F.Q`%01,`'."\n"));eval "&{'@_'}";  __END__ is near! :)

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

[Chad Granum]

I think ::Alt:: should be present in the name, though I do not care where.

Why:

 * Conveys intent better
 * Probably easier for indexes to avoid having the alt-module listed as the
newest version of the non-alt module
 * Cpan-testers can filter based on it.

Essentially everything boils down to making tooling and expectations easier
if one of Alt::/::Alt::/::Alt are required in the namespace.

I do not like the idea of making everyone have to go out of there way to
look for documentation that explicitly states that the module is
alt/non-alt. I do not trust most alt authors to make it clear in docs that
their module is alt (ribaushi is one of very few people who I do trust to
get this all correct).

Enforcing that 'Alt' be present somewhere feels like a win to me in
reducing cognitive overhead of users, and making some tooling easier.

-Chad

On Thu, Oct 26, 2017 at 9:31 AM, David Golden  wrote:

> On Thu, Oct 26, 2017 at 11:29 AM, Chad Granum  wrote:
>
>> I have a small objection to putting an alt module in a namespace other
>> than alt: It is less obvious. If I see Alt::Thing I will simply know it
>> will replace Thing.
>>
>
>
> Consider, too, if someone else wants to another alternative Thing.
> Alt::Thing2 -- is that a second Alt::Thing?  Or an alternative of Thing2?
>
> Possibly namespacing like Thing::Alt::Boring would then allow
> Thing::Alt::Spiffy, etc.  But I don't want to have explicit rules about
> this.  I think intent is more important.
>
> David
>

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

[David Golden]

On Thu, Oct 26, 2017 at 11:29 AM, Chad Granum  wrote:

> I have a small objection to putting an alt module in a namespace other
> than alt: It is less obvious. If I see Alt::Thing I will simply know it
> will replace Thing.
>


Consider, too, if someone else wants to another alternative Thing.
Alt::Thing2 -- is that a second Alt::Thing?  Or an alternative of Thing2?

Possibly namespacing like Thing::Alt::Boring would then allow
Thing::Alt::Spiffy, etc.  But I don't want to have explicit rules about
this.  I think intent is more important.

David

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

[Sawyer X]

I'm wondering what happens when two projects under the same tree want
two different DBIC's.

Also, I think that Alt::* or the likes clarifies the intent to replace
something, rather than have a version of it (the way ::Tiny) does.
Basically what Chad said.

Regardless, I think Riba has a solid plan here on how to handle an
alternative fork of DBIC and that it certainly falls within "safe
habor".


On 26 October 2017 at 14:53, David Golden  wrote:
> Neil, Andreas and I got an email request from Peter Rabbitson to confirm his
> reading of the new PAUSE operating model.  I see no reason for this
> discussion to be secret so I'm emailing cpan-workers for opinions, as
> suggested in the operating model document.  While PAUSE admins will make a
> final decision on this matter, I welcome non-admin opinions about the
> situation.
>
> Peter wants to know if his intended approach for alternative distributions
> falls under a "safe harbor" clause of the operating model.
>
> Specifically, the operating model says:
>
> "As a general rule, installing an indexed distribution (i.e. tarball, zip
> file), should not change post-install module loading for any package that is
> not indexed to that distribution... 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."
>
> Peter's desire is to release Alt::* style modules whose raison d'être is to
> provide a drop in replacement:
>
>> As stated on the mailing list many moons ago, soon after the new
>> DBIx::Class management gets on with development I intend to ship my own
>> versions of these modules under a "fail-safe Alt::-like system". The indexed
>> namespace will of course have a different name ( DBIx::Class::Boring as
>> working title ), but will install over preexisting DBIx::Class* modules IFF
>> it recognizes what it is about to overwrite as being the contents of
>> DBIx::Class 0.082840 or earlier ( I will simply hash every file ever shipped
>> by myself, and compare against this whitelist of what is safe to overwrite
>> ). Failing that the installation will abort and a user will have to set a
>> specific environment variable in order to proceed further. I intend to trial
>> this with SQL::Abstract::Boring first. Given the available ecosystem
>> installers, this is the closest thing I can come up with while leaving a
>> choice to the userbase.
>
>
> What do we think about this?  Do we feel it falls under the 'safe harbor'
> exception?  If not, what would Peter need to do to be protected by it?
>
> 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.
> 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 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.
> 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..
> I have no objection to "DBIx::Class::Boring" as a name.  I don't think we
> should mandate a convention of "Alt::*".
>
> What do others think?
>
> David
>
>
> --
> David Golden  Twitter/IRC/GitHub: @xdg

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

[Chad Granum]

I think alt modules are fine.

I am fine with an env-var solution, BUT I am now ok with a single env var
that allows any alt module in. I would recommend either a standard such as
PERL_ALLOW_ALT_[MODULE_NAME], or PERL_ALLOW_ALT="Alt::One,Alt::2". I doubd
anyone wants to allow arbitrary alt modules as opposed to specific alt
modules.

I have a small objection to putting an alt module in a namespace other than
alt: It is less obvious. If I see Alt::Thing I will simply know it will
replace Thing. The same is not obvious for the ::Boring postfix. People
make ::Tiny, ::Simple (and in my case ::LessClever) namespaces all the
time, which emulate the behavior of an existing module, but do not actually
replace it. This is not a killer issue for me, just a preference. I also
think the Alt:: namespace will make things easier on cpan-testers who do
not want an accidental override of the default implementation of a
namespace.

Riba mentioned making it NOT prompt for upgrading from versions older
than 0.082840, and not prompting if the alt:: is already installed. I am
perfectly fine with skipping the prompt if an older version of the Alt:: is
already installed, that makes complete sense to me. I am torn on the lack
of prompt when upgrading from a version before the fork. I think the
benefit of not needing to confirm the install DOES NOT outweigh the
importance of making sure people know that they are getting an Alt::
module, possibly by accident.

-Chad

On Thu, Oct 26, 2017 at 5:53 AM, David Golden  wrote:

> Neil, Andreas and I got an email request from Peter Rabbitson to confirm
> his reading of the new PAUSE operating model.  I see no reason for this
> discussion to be secret so I'm emailing cpan-workers for opinions, as
> suggested in the operating model document.  While PAUSE admins will make a
> final decision on this matter, I welcome non-admin opinions about the
> situation.
>
> Peter wants to know if his intended approach for alternative distributions
> falls under a "safe harbor" clause of the operating model.
>
> Specifically, the operating model says
> 
> :
>
> "As a general rule, installing an indexed distribution (i.e. tarball, zip
> file), should not change post-install module loading for any package that
> is not indexed to that distribution... 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."
>
> Peter's desire is to release Alt::* style modules whose raison d'être is
> to provide a drop in replacement:
>
> As stated on the mailing list many moons ago, soon after the new
>> DBIx::Class management gets on with development I intend to ship my own
>> versions of these modules under a "fail-safe Alt::-like system". The
>> indexed namespace will of course have a different name (
>> DBIx::Class::Boring as working title ), but will install over preexisting
>> DBIx::Class* modules IFF it recognizes what it is about to overwrite as
>> being the contents of DBIx::Class 0.082840 or earlier ( I will simply hash
>> every file ever shipped by myself, and compare against this whitelist of
>> what is safe to overwrite ). Failing that the installation will abort and a
>> user will have to set a specific environment variable in order to proceed
>> further. I intend to trial this with SQL::Abstract::Boring first. Given the
>> available ecosystem installers, this is the closest thing I can come up
>> with while leaving a choice to the userbase.
>>
>
> What do we think about this?  Do we feel it falls under the 'safe harbor'
> exception?  If not, what would Peter need to do to be protected by it?
>
> 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.
>- 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 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 -

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

[David Golden]

Neil, Andreas and I got an email request from Peter Rabbitson to confirm
his reading of the new PAUSE operating model.  I see no reason for this
discussion to be secret so I'm emailing cpan-workers for opinions, as
suggested in the operating model document.  While PAUSE admins will make a
final decision on this matter, I welcome non-admin opinions about the
situation.

Peter wants to know if his intended approach for alternative distributions
falls under a "safe harbor" clause of the operating model.

Specifically, the operating model says

:

"As a general rule, installing an indexed distribution (i.e. tarball, zip
file), should not change post-install module loading for any package that
is not indexed to that distribution... 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."

Peter's desire is to release Alt::* style modules whose raison d'être is to
provide a drop in replacement:

As stated on the mailing list many moons ago, soon after the new
> DBIx::Class management gets on with development I intend to ship my own
> versions of these modules under a "fail-safe Alt::-like system". The
> indexed namespace will of course have a different name (
> DBIx::Class::Boring as working title ), but will install over preexisting
> DBIx::Class* modules IFF it recognizes what it is about to overwrite as
> being the contents of DBIx::Class 0.082840 or earlier ( I will simply hash
> every file ever shipped by myself, and compare against this whitelist of
> what is safe to overwrite ). Failing that the installation will abort and a
> user will have to set a specific environment variable in order to proceed
> further. I intend to trial this with SQL::Abstract::Boring first. Given the
> available ecosystem installers, this is the closest thing I can come up
> with while leaving a choice to the userbase.
>

What do we think about this?  Do we feel it falls under the 'safe harbor'
exception?  If not, what would Peter need to do to be protected by it?

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.
   - 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
   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.
   - 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..
   - I have no objection to "DBIx::Class::Boring" as a name.  I don't think
   we should mandate a convention of "Alt::*".

What do others think?

David


-- 
David Golden  Twitter/IRC/GitHub: @xdg