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 <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: > > "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
