[swift-build-dev] How to use the Package.pins file
Daniel Dunbar
daniel_dunbar at apple.com
Tue Dec 20 14:24:37 CST 2016
The intended use is that:
1. Your manifest specifies your "ideal" range. If your dependencies are using semver properly, then this should be the "lowest version your app requires", based on the API it uses from that dependency. The only intended reason to deviate from this is if there are bugs or known incompatibles between the package and its dependency.
2. The pin file is used to select the exact version, so that different team members see consistent behavior (in a nutshell).
3. The flexibility in the manifest specification *documents* the compatibility your app *should* have, so that the tools can provide you with workflows to, for example, update to a newer version of a dependency to try it out (maybe they made it faster, fixed bugs, etc.).
#3 is the "benefit" you are gaining from having similar information in two different places.
One way to think of it is that #1 is simply a "fact" -- "what is the absolute minimum version of this package the code requires", and #2 is a choice "what version would *I* like to use".
- Daniel
> On Dec 20, 2016, at 6:13 AM, Steven Clukey via swift-build-dev <swift-build-dev at swift.org> wrote:
>
>
>> Loose specifications allow libraries to avoid unnecessarily causing dependency conflicts for one another.
>
>
> I agree, and SE-0145 specifically recommends against using pinning for libraries.
>
>
>
>> The "pins" file allows application builds to reliably produce the same resolution, time after time.
>
>
> If an application requires the exact same dependency version resolution, then why not put an exact version in the manifest? What is the point, or the benefit, of using a loose version in the application's manifest plus an exact version in the "pins" file instead of just using an exact version in the manifest to begin with?
>
>
>
> Steven
>
>
>
> _______________________________________________
> swift-build-dev mailing list
> swift-build-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-build-dev
More information about the swift-build-dev
mailing list