> On Oct 14, 2016, at 4:02 PM, Paul Cantrell <[email protected]> wrote: > > Sorry for the late arrival to this thread. Comments below… > >> On Oct 14, 2016, at 3:09 PM, Daniel Dunbar via swift-build-dev >> <[email protected]> wrote: >> >> What this proposal about is in one sense being able to export and share >> those pins. > > This is a crucial and clarifying insight. It should be in the proposal! Near > the top.
Good idea, will incorporate it. >> 2. Huon, Alexis, and I all agree we should never *inherit* pins by default. > > Indeed. Pins should be only be about sharing specific versions within a > development team — not with client packages / apps. What’s pinned in Vegas > stays in Vegas. Publishing pins to other projects would be nonsensical. > >> 5. Given that many people agree there are two workflows (we ourselves had >> talked about this a lot when writing the proposal, but didn't put it in), we >> felt it makes sense to consider adding that as an explicit declaration >> *somewhere*. >> >> @Eloy, @Orta: Suppose we had a semantic notion of which packages were >> intended to be "top-level" versus used as a dependency, and we chose our >> defaults accordingly (in this case, we would orient workflows towards >> pinning by default in the top-level case, in the used as a dependency case >> we would orient away from it, e.g. warning you if you checked it in). What >> would you think of such a design? > > I’m puzzled. If a package’s pinning does not affect any other package that > uses it, why should the defaults be different? A library will still suffer > from all the “works for me” problems an app might. > > Is the rationale that not pinning libraries encourages accidental testing of > new versions of a library’s dependencies as they arrive? Or is there another > rationale for having different defaults? I'll defer to this comment (linked from someone else earlier in the thread), which happens to match up with my perspective: https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537 - Daniel > > Cheers, P > _______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
