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
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to