[swift-build-dev] [swift-evolution] [Review] SE-0145: Package Manager Version Pinning (Revised)
Martin Waitz
tali at admingilde.org
Thu Nov 24 09:30:19 CST 2016
Hello,
Am 2016-11-24 13:54, schrieb Alex Blewitt via swift-evolution:
> At the moment, the proposal suggests having a secondary 'pins' file,
> which exists to allow explicit dependencies to be checked in to
> version control. This can be done at the moment, using a
> Version(1,2,3) or range Version(1,2,3)...Version(1.2.3) in the
> constraints.
>
> What the proposal doesn't bring forward clearly is the versioning of
> transitive dependencies, and whether or not those dependencies violate
> the requirement constraints. For example, if A depends on B, and B
> depends on C version 1.2.3+, can or should A pin C version 0.9.9? What
> if A depends on B and D, both of which depend on different versions of
> C that may be semantically equivalent (e.g. C version 1.2.3 and C
> version 1.4.5)? This will come up more often than the 'fail to build'
> approach outlined in the proposal.
be careful and do not mix up `Package.swift` and `Package.pins`.
Both are used for different things:
* Package.swift is used to specify compatible versions of dependencies.
These always apply.
In your example above, a `swift update` would need to find a set of
versions
for B, C, and D where all these version requirements are met.
Therefor, Package.swift ranges should be as broad as possible,
to make it possible to find compatible versions.
* Package.pins stores the current set of all (transitive) dependencies.
It is stored in the toplevel project (A) and would pin one set of
compatible
(and hopefully tested) versions of B, C and D.
This way you always get a clean state when you start working on A.
Then, when you run `swift package update` in A, it will try to find a
newer set of
B, C, and D, by looking at all of the `Package.swift` files.
This new set will then be written to `Package.pins` so that everybody
can benefit from the update.
It's important to not hard-code specific versions into `Package.swift`
as this complicates the version resolution during update and could lead
to the conflicting version requirements you describe.
--
Martin
More information about the swift-build-dev
mailing list