[swift-build-dev] [swift-evolution] Proposal: Package Manager Version Pinning
daniel_dunbar at apple.com
Fri Oct 14 18:42:54 CDT 2016
> On Oct 14, 2016, at 4:02 PM, Paul Cantrell <cantrell at pobox.com> 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 <swift-build-dev at swift.org> 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:
> Cheers, P
More information about the swift-build-dev