[swift-build-dev] [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)

[Daniel Dunbar]

> On Nov 23, 2016, at 3:03 PM, Martin Waitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
>> The review of "SE-0145: Package Manager Version Pinning" begins again after revisions, starting now and running through November 28th. The proposal is available here:
>> 
>> 	https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md <https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md>
>> 
> 
> 
>> What is your evaluation of the proposal?
> 
> +1
> I think this is an important change for the Swift package ecosystem.
> Having reproducible builds by default is a big step forward.
> Storing the version of all dependencies in version control and having an easy way to update them helps to reduce maintenance overhead of packages.
> 
> I have two comments / requests for improvement:
>  * Having two completely separate modes (—enable-autopin vs. —disable-autopin) with a different semantic (e.g. for `swift update`) unnecessarily complicates the design. I understand that there are different use cases where packages have to be handled differently, however I think we should invest some more time on understanding these use cases (see below).

I agree, I am not very happy with this part.

However, I expect that in practice what will happen is almost all projects will simply fall into one of the two camps, they either use auto pinning or not. For developers working on that package, their workflow will then end up being consistent. For developers who end up working on a bunch of projects with inconsistent choices, then I agree it might be somewhat confusing, and I hope the diagnostics will end up addressing this.

I still think that this is a better compromise than a more complex (but consistent) mechanism like the one you propose. I think we should gain some experience with the proposed mechanism and then see if we feel it needs revision in practice.

 - Daniel

>  * For me the term ‚pin‘ (just like ‚lock‘) implies that the version of pinned dependencies should be fixed and should therefore not be changed/updated. (But I’m not a native speaker, so you may have other associations here.) We should make clear that we *manage* dependencies and that dependencies should be easy to update even while they can be reproduced exactly.
> 
> Let’s look at the features of the proposal and how they can be used:
>  * Defines two groups of dependencies (pinned vs. unpinned) where one group can be updated independently;
>  * unpinned dependencies are automatically updated on clone, not just on update;
>  * updates of unpinned dependencies are not considered a change in the package’s repository.
> This can be used to easily update internal dependencies while keeping the same version of external dependencies.
> Or to keep some difficult-to-update dependencies while constantly updating all the other dependencies.
> Or to not create git changes for some selected dependencies.
> You name it.
> 
> Basically it boils down to better control when and how dependencies are updated.
> However, I’m not yet convinced that the proposed pinning system is the best way to do that.
> Why only support two groups? Why these two modes of operation? Why not support a specific set of dependencies which are unmanaged while still tracking all new dependencies?
> 
> When we want to create groups of dependencies and handle them differently, then we should do that explicitly, by introducing groups which can be defined by the package maintainer.
> 
> E.g.:
> 
> 	swift package dependency <dep-name> —group <group-name>
> 
> We could store each group in a file of its own (e.g. `Package-<group-name>.versions` or whatever) and the maintainer could put each one under version control or not as he likes.
> 
> A whole group could be updated in one go:
> 
> 	swift package update —group internal
> 
> This could simulate the pinning as described in the proposal:
> 
> 	swift package dependency A —group unpinned
> 	swift package dependency B —group pinned
> 	echo Package-unpinned.versions > .gitignore
> 	git add .gitignore Package-pinned.versions
> 
> Each group can be updated individually and the package maintainer can put this group under version control or not.
> One group would have to be special to automatically include all new dependencies.
> Other than that we would not need any special handling ala —repin/—enable-autopin. Groups could be defined to make updating related packages easier.
> When needed, we could even set some groups to update automatically on build (not only on clone/update).
> This could be useful for closely related packages. Why should clone be special anyways?
> 
> 
>>  Is the problem being addressed significant enough to warrant a change to Swift?
> 
> Yes.
> Not managing the package dependencies would unnecessarily complicate package maintenance in the long term.
> 
> 
>> Does this proposal fit well with the feel and direction of Swift?
> 
> Yes.
> Reproducible builds fit well into the safe-by-default approach of Swift.
> 
> 
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
> 
> I always hated `npm` and all those node packages which had overly restrictive dependency requirements.
> I guess these were used in order to have more control about which version to use, but this resulted
> in both packages which I could not build out of the box (because some dependencies changed),
> and packages I could not update because of conflicting requirements.
> Using loose version requirements + semver in `Package.swift` files together with exact versions
> of all dependencies stored in the top-level package solves everything: you get reproducible builds
> (based on `Package*.versions`) together with easy updates (based on all packages’ `Package.swift`).
> 
> 
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> 
> 
> Read both versions of the proposal, took part in the discussion.
> 
> — Martin Waitz
> _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20161128/3fd20c87/attachment.html>