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
