[swift-evolution] [Review] SE-0150 Package Manager Support for branches

[Rick Ballard]

> On Jan 25, 2017, at 11:06 PM, Martin Waitz via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Hello Boris,
> 
>> Am 25.01.2017 um 19:10 schrieb Boris Buegling <bbuegling at apple.com <mailto:bbuegling at apple.com>>:
>>> But instead of hard-coding some version into the manifest, we should allow to specify dependencies without any version requirement.
>>> The concrete branch/version specification should always be stored in the `Package.pins` file.
>>> This way, we also don't have any problem with conflicting branch specifications.
>> 
>> While this is true for most packages, some have a development model where they will always depend on a branch and never on a version. In that case, it is more semantically correct to have the branch definition in the manifest, otherwise the package would not be able to build without a pins file. 
>> 
>> This is especially true for the example from the proposal:
>> 
>> A -> (B:master, C:master) B -> D:branch1 C -> D:branch2
>> 
>> Since the pins file of packages B and C would not be considered when building A, you would need to lift the pinning that is inherent to those packages up to the pins file of A.
> 
> OK, you are right, branches can be helpful to have in the manifest.
> But I’m still confident that we must not put explicit version information into it.
> They belongs into the `Package.pins` file.
> That is enough to get reproducible builds.

Hi Martin,

By "explicit version information", do you mean that you shouldn't put a git revision hash in the manifest – only branches and version tags should be acceptable?

I'd agree that the revision-based initializer is a marginal feature; normally your package should depend on a version range or is tracking a branch. That said, we can imagine that you might wind up needing to peg your dependency to a specific revision that isn't a version tag, and not track a moving branch, so this seemed like a fairly harmless feature to add for that case. What is your objection about supporting that?

The decision about whether to put this information in your pins or in your manifest should be driven by whether it's something your package requires, or is just a workflow choice. If you just want to temporarily stick to a specific revision of your dependency for workflow reasons, pinning is the right way to do that. If, however, your package currently requires that revision, and isn't going to work properly without it, then the manifest is the right way to express that. You'd want that specification to stick even if someone did `swift package update --repin` to get newer pinned revisions.

	- Rick

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20170130/bcb212dd/attachment.html>