[swift-evolution] [Review] SE-0145: Package Manager Version Pinning

[Martin Waitz]

> What is your evaluation of the proposal?

+1 for using reproducible versions of dependencies
-1 for the actual proposal

My problem with this proposal is that it tries to please everybody by introducing options everywhere.
I think we should try to build a system which is robust and works all of the time.

Being able to reproduce any build is a great value, no matter which package we are working on.
We should build our package management in a way that reproducible builds are the default.
Therefor I strongly propose to always store the exact version of all dependencies under
version control.

Just adding opt-ins (pinning of individual packages) creates new problems:
How should the user/maintainer select which packages to pin? How do we maintain this list?
E.g. even after the proposed `swift package pin —all`, you can end up with unpinned dependencies
after a `swift package --repin` when one dependency introduces some new sub-dependency.
Or should we also pin these sub-dependencies when the parent was already pinned?
But then what to do when the newly introduces sub-dependency was already part of the
closed set of all dependencies before, but was explicitly not pinned?

We should just drop all these problems and design a system which works for all use-cases
without having to manually pin dependencies.
Just store the version of all dependencies but make it easy to change/update them.
Of course, the used versions must be under control of the top-level package which is being built.
All the version information stored within dependencies may be a nice hint for the top-level
maintainer, but should not be used by the build system.
This way, we don’t have to differentiate between top-level and library packages.

I don’t think we have to be worried about weakening semver compatibility.
Library packages will be included by many top-level packages, each with their own
update cycle. Each update will be performed according to the semver specification.
CI systems also do not have to just build the current version, but could also use
an extra builder which first updates all dependencies and then does its tests.
Not versioning some dependencies does not provide any benefit here.
I also agree that it’s good to encouraging frequent updates, but we should find a different means.
We should make it easy to update dependencies, but leave it to each package maintainer to control
when and what to update.

If we don’t ‚pin‘ individual packages but simply store all versions, then I also propose
to use the name `Package.versions` for our new file.


> Is the problem being addressed significant enough to warrant a change to Swift?

yes.
Reproducible builds are important and should be supported by swift-pm.


> Does this proposal fit well with the feel and direction of Swift?

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.versions`).


> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?

Read the proposal and the comments.

-- Martin