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 <x...@xdg.me> 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 > <https://github.com/andk/pause/blob/master/doc/operating-model.md#47-treading-on-another-authors-toes-namespaces-or-permissions> > : > > "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 <x...@xdg.me> Twitter/IRC/GitHub: @xdg >
