* David Golden <x...@xdg.me> [2017-10-26 14:58]: > What do we think about this? Do we feel it falls under the 'safe > harbor' exception?
As far as I can see, the mechanism described by Peter does not permit scenarios in which a user unwittingly gets their Perl installation screwed over by DBIx::Class::Boring. As such, it seems to me that the mechanism follows the spirit of the principles, and therefore should clearly fall under the safe-harbour clause in question. > 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. I don’t think so, and think it’s fine to not require it. But you didn’t state a reason why you think that so I don’t know whether I disagree with you. In particular, requiring an opt-in even in presence of a hash match interacts badly with the fact that the actual codebase in the fork will be staying in the DBIx::Class namespace for at least a very long time, because it means that an opt-in is required not only for switching to the fork, but also for all upgrades *after* following the fork. Such a requirement would therefore mean that users who intend to stay on the DBIx::Class::Boring fork, or who use a downstream project that has chosen the DBIx::Class::Boring fork, will forever be needing to shim the setting of this environment variable into their toolchain or deploy machinery. OTOH, I believe upgrading users of a forked module from a pre-fork version to the post-fork codebase is fine *so long as* the fork has a sufficiently strong backcompat commitment to pre-fork versions. And as far as that applies to DBIx::Class::Boring, the most neutral way I can express myself is that the entire situation came to a head because Peter’s commitment to backcompat has been perceived as *too* overriding. These are my reasons to believe that explicit opt-in under pure-upgrade situations (as opposed to switching an installation over from the other fork) is neither necessary nor reasonable under the mechanism described in the proposal you quoted. > 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). The proposal you quoted says that the installation will *abort*, without even a prompt, unless explicit opt-in via environment variable is given. Therefore this requirement is fulfilled in spades. > - 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. (See right above.) > - 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.. Generally, yes. But I have to agree with Chad on this point: an opt-in should be specific to particular modules, and not limit the user to expressing a blanket “I accept any Alt:: that might be listed anywhere in my dep chain”. In fact I raised this exact issue a long time ago: https://github.com/ingydotnet/alt-pm/issues/3 It’s fine for there to be a convention for such opt-ins. It’s possibly even a good idea (if it comes up in enough different cases in practice to matter). Peter’s proposal in particular is already sane on that specific front. > - I have no objection to "DBIx::Class::Boring" as a name. I don't > think we should mandate a convention of "Alt::*". Agree. I believe that conveying intent through the name is imperative only when the protection of users at install time is too weak – as it has been in Ingy’s conception of the Alt:: concept. Regards, -- Aristotle Pagaltzis // <http://plasmasturm.org/>
