[swift-evolution] [Review] SE-0150 Package Manager Support for branches
bbuegling at apple.com
Wed Jan 25 12:10:08 CST 2017
> On 25 Jan 2017, at 10:40, Martin Waitz via swift-evolution <swift-evolution at swift.org> wrote:
> Am 2017-01-24 19:18, schrieb Daniel Dunbar via swift-evolution:
>> The review of SE-0150 “ Package Manager Support for branches" begins
>> now and runs through January 31, 2017. The proposal is available here:
>> What is your evaluation of the proposal?
> I think we should more clearly separate the contents of the manifest and the version pins file.
> I don't like to have two competing ways to do the same thing.
> The manifest file (`Packages.swift`) should contain all required dependencies while the pins file should contain specific versions.
> If there the dependency has no released version yet that is fine!
> 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.
Additionally, I think the proposed errors for invalid dependencies should ensure that this will not become an issue in practice.
>> Is the problem being addressed significant enough to warrant a change to Swift?
> Bootstrapping and the ability to work with unreleased dependencies are important.
>> Does this proposal fit well with the feel and direction of Swift?
> I'd like to keep the clear separation between `Package.swift` and `Package.pins`.
>> If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those?
>> How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
> Quick Reading.
> swift-evolution mailing list
> swift-evolution at swift.org
More information about the swift-evolution