> On Oct 14, 2016, at 7:18 PM, Daniel Dunbar <daniel_dun...@apple.com> wrote:
>> On Oct 14, 2016, at 4:51 PM, Paul Cantrell via swift-evolution
>> <email@example.com> 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
> On Oct 14, 2016, at 7:17 PM, Alexis Beingessner <abeingess...@apple.com>
> A few comments down, Yehuda even provides an example of him doing just that
> with Bundler:
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.
swift-evolution mailing list