On Mon, Oct 30, 2017 at 3:11 AM, Aristotle Pagaltzis <pagalt...@gmx.de> wrote:
> > - 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. > Even if Peter's mechanism is in the spirit of the operating model, I would prefer the higher standard of "explicit confirmation" as the operating model call for. If you need a rationale -- practically speaking -- consider this scenario: 1. User without DBIC or DBIC::Boring installs some module Foo that depends on DBIC::Boring; DBIC::Boring gets silently installed. 2. User installs some module Bar that depends on DBIC; because DBIC doesn't check for conflicts with DBIC::Boring, it silently overwrites it. 3. Foo is now broken. User doesn't know why. Whereas if in #1, the user had to opt into DBIC::Boring, then they would be accepting the risk of future breakage from DBIC conflicts. Further, while I trust Peter to be sufficiently clever and user-considerate in his Alt-style design, I don't want the lead-off precedent to depend on cleverness because I don't trust anyone modeling their work on Peter's will exercise the same level of care and diligence. > 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. > > I believe that is a feature, not a bug. Among other things, such an environment variable will show up in "perl -V" output, CPAN Testers reports and analytics, etc. which might help diagnose any unexpected complications from using Alt-style modules. David -- David Golden <x...@xdg.me> Twitter/IRC/GitHub: @xdg
