> On Oct 14, 2016, at 7:18 PM, Daniel Dunbar <[email protected]> wrote: > >> >> On Oct 14, 2016, at 4:51 PM, Paul Cantrell via swift-evolution >> <[email protected]> wrote: >> >> That’s clearly a bigger, separate idea, not necessary to hash out right now. >> I mean it just to illustrate what better approaches might look like. I’m >> skeptical that simply disabling pinning does a good job of solving the >> intended problem, and don’t think it should weigh quite so heavily on the >> proposal at hand. > > The current idea wouldn't "disable it”
Right, my bad wording. Is “turn off / discourage pinfiles by default for libraries but not apps” a better description of the general idea? > it would discourage you from checking it in for a library (it really comes > down to you have to run two commands, not one). I agree all the other things > you outline are useful, and that not checking it in doesn't magically solve > the problem here. If the difference were only what’s in .gitignore, I’d be completely comfortable with that. Enthusiastic. And if there’s some distinction between libs and top-level packages that only affects a generated .gitignore and/or emitted warnings, I’d be completely comfortable with that. I’m skeptical of deeper special-casing for libs vs. top-level, but it sounds like the special-casing may not actually be that deep. If so, I’m just fussing over nothing! > On Oct 14, 2016, at 7:17 PM, Alexis Beingessner <[email protected]> > wrote: > > A few comments down, Yehuda even provides an example of him doing just that > with Bundler: > > https://github.com/yarnpkg/yarn/issues/838#issuecomment-253366352 > <https://github.com/yarnpkg/yarn/issues/838#issuecomment-253366352> Yeah, I’d love to see SwiftPM or a companion tool automate that. Totally tractable problem, and I’ll bet we see quality payoffs in the lib ecosystem. Cheers, Paul
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
