> 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 
>> <swift-evolution@swift.org> 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 <abeingess...@apple.com> 
> 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.



swift-evolution mailing list

Reply via email to