Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Daniel Dunbar via swift-evolution]

Hi Jay,

> On Oct 16, 2016, at 7:14 PM, Jay Abbott  wrote:
> 
> 
> I like the core idea here, but I feel that it could potentially prevent teams 
> updating, through focus on other things and general laziness/ignorance to 
> what's going on with external dependencies. Although this gives me a separate 
> idea...

I hope to tackle this through features which will help notify you when new 
versions you could upgrade to are available. I hope the default practice in the 
ecosystem will then become to heed those notifications and update.

> How about an additional feature that can be run manually if desired, or more 
> likely run as a daily/overnight job on CI. I'm not entirely sure what the 
> command would be or how it would work exactly, but the general idea would be:
> 
> * Build a list of dependencies that can potentially be updated (from the 
> entire dependency graph).
> * For each updatable dependency in the list {
> * Keep all the other pins as-they-were and fetch the updated dependency.
> * Build the project and run its tests.
> * Keep track of which ones worked and which ones failed.
> }
> * If there are updatable dependencies that build successfully, and all (your 
> project) tests still pass - this can to be reported to the development team.
> 
> This way, teams could use pinning and automate checking for compatible 
> updates. Also package owners could potentially be notified (with explicit 
> consent of their users) if they broke compatibility in what should have been 
> a compatible release. I realise that not everything going on here is inside 
> the remit of a package manager, but the package manager could provide 
> functionality to help with such things, a bit like git-bisect. Then again, 
> the SPM community proposal seems to cast quite a wide potential remit.
> 
> An additional cool feature would be some mechanism to allow notifications to 
> the package owner if what they have released as compatible (according to the 
> version) actually isn't. Explicit opt-in from users for this one of course, 
> with options for what information to include. Maybe swift.org 
>  could host this for package owners, and usage stats for 
> them too?

Both of the features you propose make a lot of sense to me, and are things I 
definitely would like to see us do in time.

For now, though, I see this feature as a "building block" towards those 
directions. Others can build on top of this feature to create automated systems 
like the ones you describe, I don't think we need to try and tackle everything 
ourselves in the initial proposal.

 - Daniel

> 
> On Sun, 16 Oct 2016 at 18:06 Georgios Moschovitis via swift-evolution 
> > wrote:
> > In Swift, we have pretty consistently tried to choose the "right" answer to 
> > make the resulting language consistent and beautiful.
> > I'm perfectly happy to have a discussion about the naming, but I would like 
> > it to be driven by what we believe the "right" answer is, not simply by 
> > deference to existing solutions.
> 
> +100
> 
> Moreover, after your explanation, `lock` feels wrong to me too.
> ___
> swift-evolution mailing list
> swift-evolution@swift.org 
> https://lists.swift.org/mailman/listinfo/swift-evolution 
> 

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Georgios Moschovitis via swift-evolution]

> In Swift, we have pretty consistently tried to choose the "right" answer to 
> make the resulting language consistent and beautiful.
> I'm perfectly happy to have a discussion about the naming, but I would like 
> it to be driven by what we believe the "right" answer is, not simply by 
> deference to existing solutions.

+100

Moreover, after your explanation, `lock` feels wrong to me too. 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Daniel Dunbar via swift-evolution]

> On Oct 14, 2016, at 12:04 PM, Ryan Lovelett  
> wrote:
> 
>> Whether "pinning" is the right word is a different debate, but when we view 
>> pinning as a workflow-focused feature, versus the specification in the 
>> manifest (which is the "requirement"), then I think the connotation actually 
>> works fairly well (e.g., a pinboard is something you pin to while working, 
>> or pinning a dress while you stitch it). I also wasn't a huge fan of pin 
>> initially, but as it bounced around in my head for a while I really started 
>> to like it, for exactly this connotation reason.
> 
> I think this comment drives at the core of the difference between this 
> proposal and what Orta, Alexis and others are saying. (At least for me)
> 
> The description you've provided here, specifically the word "workflow", and 
> the concept of operations described by the proprosal are meant to be a 
> transient. They are meant as a temporary description of how these 
> dependencies should be kept in order.  To my mind one "puts a pin" in 
> something temporarily. To comeback to it later to do something with it at 
> that time. Thus the pin probably does work with this concept.
> 
> Conversely, the concept of "locking" something feels less transient. It feels 
> more permanent. More like the concept of operations described by Orta, Alexis 
> and others. Idle speculation: might be why those other managers selected the 
> word lock.
> 
> Not sure where I come down on the whole thing yet. Just wanted to say that if 
> the propsal goes another way than what was first propsed a new word likely 
> should be investigated.

I agree with everything here. :)

 - Daniel

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Ryan Lovelett via swift-evolution]

> Whether "pinning" is the right word is a different debate, but when we
> view pinning as a workflow-focused feature, versus the specification
> in the manifest (which is the "requirement"), then I think the
> connotation actually works fairly well (e.g., a pinboard is something
> you pin to while working, or pinning a dress while you stitch it). I
> also wasn't a huge fan of pin initially, but as it bounced around in
> my head for a while I really started to like it, for exactly this
> connotation reason.

I think this comment drives at the core of the difference between this
proposal and what Orta, Alexis and others are saying. (At least for me)

The description you've provided here, specifically the word "workflow",
and the concept of operations described by the proprosal are meant to be
a transient. They are meant as a temporary description of how these
dependencies should be kept in order.  To my mind one "puts a pin" in
something temporarily. To comeback to it later to do something with it
at that time. Thus the pin probably does work with this concept.

Conversely, the concept of "locking" something feels less transient. It
feels more permanent. More like the concept of operations described by
Orta, Alexis and others. Idle speculation: might be why those other
managers selected the word lock.

Not sure where I come down on the whole thing yet. Just wanted to say
that if the propsal goes another way than what was first propsed  a new
word likely should be investigated.
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Daniel Dunbar via swift-evolution]

> On Oct 14, 2016, at 10:37 AM, Huon Wilson via swift-evolution 
>  wrote:
> 
> 
>> On Oct 14, 2016, at 09:43, Alexis via swift-evolution 
>> > wrote:
>> 
>> A library shouldn’t pin its dependencies, while an application should.
> 
> Not only “shouldn’t” but can’t: Rust’s cargo (I don’t know for sure about 
> Bundler and Yarn, but they’re all in the same vein, and pretty much from the 
> same person) will just ignore any non-top-level lock files, i.e. the package 
> that user is working on has a record of the exact versions of everything in 
> their dependency graph, and the user can update all or just parts of that 
> graph fairly precisely, as desired.
> 
> My impression is that other ecosystems without pinning-by-default have 
> seriously suffered from the lack of reliable reproducible builds. For 
> instance, a major complaint I have seen about "go get” is that one can come 
> back to some code after a few months to fix a minor bug and have no chance of 
> getting the code to compile, basically just requiring a full rewrite, because 
> dependencies' code has changed (or disappeared entirely) and there’s no 
> record of what the original was, despite your code being completely untouched 
> in all that time.

This wouldn't have been our behavior under this proposal, unless you recloned 
the package. Maybe that is what you meant though?

> Of course, a hard push towards API-level semantic versioning may allay the 
> worst of the code-changing problems, but unless there’s going to be some 
> seriously fancy static analysis (something something halting problem), there 
> will be a lot of breaking changes that can’t be picked up.
> 
> ---
> 
> To reframe the discussion slightly, not pinning dependencies effectively 
> means that the tools are making “random" changes to your code outside your 
> control. Sure, those changes were transitively made by 
> possibly-computer-assisted humans and may fix bugs, but those pesky meat-bags 
> can still make mistakes, and, they don’t see the interactions between all the 
> different packages in your specific application.
> 
> IME having the predictability of “never changing code under my feet” combined 
> with pervasive semantic versioning hits an empowering middle ground of being 
> able to depend on many & varied packages and update them to the latest 
> versions without fear (for one, it’s easy to revert the lock file if 
> something breaks during an update). Feedback from others about cargo is the 
> same, often along the lines of “it’s the best package manager I’ve ever used”.

To be clear, exactly when are you expecting the tools to "change code under my 
feet".

In our design, the only time we ever change a *local build* is in response to 
an explicit user action, so we aren't changing code under your feet necessarily.

If you throw away a checkout, and fetch it again, then yes we get a different 
version. Is this the use case you are talking about (and by implication talking 
about committing the file)?

If you reset your local workspace completely, then yes we will get a different 
version (since we had to reclone).

I just want to make sure it is clear to everyone that we are not proposing we 
automatically change your build version underneath you any time we happen to 
fetch something new from the package. We only update in response to user action.

> Also, more on the side of implementation details, having a lock file by 
> default probably mean one can (get closer to) never hitting the network 
> unless the user asks for it, making working offline or on a 
> low-speed/high-latency connection easier, i.e. no need to check for new 
> versions of the whole dependency graph on O(every) build, which aggressively 
> keeping everything up to date would seemingly have to do? (I don’t know 
> swift-pm’s current behavior here, so maybe there’s some tricks that avoid it.)

This is part of the proposed design (this is the current implementation, 
really), FWIW, although that may not have been clear at all.

 - Daniel

> 
> Huon
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Daniel Dunbar via swift-evolution]

> On Oct 14, 2016, at 9:43 AM, Alexis via swift-evolution 
>  wrote:
> 
> 
> 
>> On Oct 14, 2016, at 2:01 AM, Ankit Aggarwal via swift-evolution 
>> > wrote:
>> 
>> Hi,
>> 
>> We're proposing version pinning feature in Swift Package Manager. The 
>> proposal is available here 
>> 
>>  and also in this email:
>> 
>> Feedback welcomed!
>> 
>> Thanks,
>> Ankit
>> 
>> 
>> 
>> Package Manager Version Pinning
>> Proposal: SE-
>> Author: Daniel Dunbar , Ankit Aggarwal 
>> 
>> Review Manager: TBD
>> Status: Discussion
>> Introduction
>> This is a proposal for adding package manager features to "pin" or "lock" 
>> package dependencies to particular versions.
>> 
>> Motivation
>> As used in this proposal, version pinning refers to the practice of 
>> controlling exactly which specific version of a dependency is selected by 
>> the dependency resolution algorithm, independent from the semantic 
>> versioning specification. Thus, it is a way of instructing the package 
>> manager to select a particular version from among all of the versions of a 
>> package which could be chosen while honoring the dependency constraints.
>> 
>> Terminology
>> 
>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>> since the term "lock" is already overloaded between POSIX file locks and 
>> locks in concurrent programming.
>> 
> I’ve never seen this cause any actual confusion, nor has anyone I know who 
> teaches/develops these sorts of tools. As far as I can tell, the broader 
> programming community is rapidly converging on this as standard terminology:
> 
> * Gemfile.lock (Ruby)
> * Cargo.lock (Rust)
> * Composer.lock (PHP)
> * yarn.lock (JS)
> * pubspec.lock (Dart)
> * Podfile.lock (Swift/Objc!)
> 
> Diverging from this seems counter-productive.

I replied to Max on this point, can you check that?

I will add that I am completely open to being compelled by "this is becoming 
standard, we should follow".

Also, let's break this into its own fork of the thread rather than mix with the 
behavior.
>> Philosophy
>> 
>> Our philosophy with regard to pinning is that we actively want to encourage 
>> packages to develop against the latest semantically appropriate versions of 
>> their dependencies, in order to foster rapid development amongst the 
>> ecosystem and strong reliance on the semantic versioning concept. Our design 
>> for version pinning is thus intended to be a feature for package authors and 
>> users to use in crafting specific workflows, not be a mechanism by which 
>> most of the packages in the ecosystem pin themselves to specific versions of 
>> each other.
>> 
>> Use Cases
>> 
>> Our proposal is designed to satisfy several different use cases for such a 
>> behavior:
>> 
>> Standardizing team workflows
>> 
>> When collaborating on a package, it can be valuable for team members (and 
>> continuous integration) to all know they are using the same exact version of 
>> dependencies, to avoid "works for me" situations.
>> 
>> This can be particularly important for certain kinds of open source projects 
>> which are actively being cloned by new users, and which want to have some 
>> measure of control around exactly which available version of a dependency is 
>> selected.
>> 
>> Difficult to test packages or dependencies
>> 
>> Complex packages which have dependencies which may be hard to test, or hard 
>> to analyze when they break, may choose to maintain careful control over what 
>> versions of their upstream dependencies they recommend -- even if 
>> conceptually they regularly update those recommendations following the true 
>> semantic version specification of the dependency.
>> 
>> Dependency locking w.r.t. deployment
>> 
>> When stabilizing a release for deployment, or building a version of a 
>> package for deployment, it is important to be able to lock down the exact 
>> versions of dependencies in use, so that the resulting product can be 
>> exactly recreated later if necessary.
>> 
>> Proposed solution
>> We will introduce support for an optional new file Package.pins adjacent to 
>> the Package.swift manifest, called the "pins file". We will also introduce a 
>> number of new commands (see below) for maintaining the pins file.
>> 
>> This file will record the active version pin information for the package, 
>> including data such as the package identifier, the pinned version, and 
>> explicit information on the pinned version (e.g., the commit hash/SHA for 
>> the resolved tag).
>> 
>> The exact file format is unspecified/implementation defined, however, in 
>> practice it will be a JSON data file.
>> 
>> This file may be checked into SCM by the user, so that its effects apply to 
>> all users of the package. However, it may 

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Daniel Dunbar via swift-evolution]

> On Oct 14, 2016, at 10:03 AM, Max Desiatov via swift-evolution 
>  wrote:
> 
> The other point is that when working in a multi-language environment, having 
> conventions such as this broken causes additional mental burden. That is, 
> after working with JavaScript/Rust/iOS with CocoaPods and then switching to 
> Swift, would require a lot of unneeded context switching, as in: "Where's 
> that lockfile? I can't find it. Oh great, turns out it's not a lockfile, it's 
> something else".

In Swift, we have pretty consistently tried to choose the "right" answer to 
make the resulting language consistent and beautiful.

I'm perfectly happy to have a discussion about the naming, but I would like it 
to be driven by what we believe the "right" answer is, not simply by deference 
to existing solutions. I do sympathize with wanting to be consistent where 
there is little value in diverging, but most people I have discussed this with 
agree that "lock" is actually the *wrong* word to use for this operation.

Also, please be mindful that your perspective is biased by the tools you are 
familiar with. Python's pip tool, for example, uses "freeze" for this, and 
Heroku expects "requirements.txt", so someone coming from that ecosystem could 
make the same argument in another direction. I find arguments about "A does X 
so we should do X" most compelling when it comes with a relatively complete 
survey of existing tools. not just a particular slice of possible tools.

Whether "pinning" is the right word is a different debate, but when we view 
pinning as a workflow-focused feature, versus the specification in the manifest 
(which is the "requirement"), then I think the connotation actually works 
fairly well (e.g., a pinboard is something you pin to while working, or pinning 
a dress while you stitch it). I also wasn't a huge fan of pin initially, but as 
it bounced around in my head for a while I really started to like it, for 
exactly this connotation reason.

 - Daniel

> 
> With best regards, Max.
> 
>> On 14 Oct 2016, at 17:59, Max Desiatov > > wrote:
>> 
>> I also agree with the point that .lock extension better suits here and 
>> adheres to a convention already established in other languages. I personally 
>> would prefer the file to be named Package.lock, not Package.pins and also 
>> think that it would help newcomers who already used other package managers, 
>> especially CocoaPods.
>> 
>> With best regards, Max.
>> 
>>> On 14 Oct 2016, at 17:43, Alexis via swift-evolution 
>>> > wrote:
>>> 
>>> 
>>> 
 On Oct 14, 2016, at 2:01 AM, Ankit Aggarwal via swift-evolution 
 > wrote:
 
 Hi,
 
 We're proposing version pinning feature in Swift Package Manager. The 
 proposal is available here 
 
  and also in this email:
 
 Feedback welcomed!
 
 Thanks,
 Ankit
 
 
 
 Package Manager Version Pinning
 Proposal: SE-
 Author: Daniel Dunbar , Ankit Aggarwal 
 
 Review Manager: TBD
 Status: Discussion
 Introduction
 This is a proposal for adding package manager features to "pin" or "lock" 
 package dependencies to particular versions.
 
 Motivation
 As used in this proposal, version pinning refers to the practice of 
 controlling exactly which specific version of a dependency is selected by 
 the dependency resolution algorithm, independent from the semantic 
 versioning specification. Thus, it is a way of instructing the package 
 manager to select a particular version from among all of the versions of a 
 package which could be chosen while honoring the dependency constraints.
 
 Terminology
 
 We have chosen to use "pinning" to refer to this feature, over 
 "lockfiles", since the term "lock" is already overloaded between POSIX 
 file locks and locks in concurrent programming.
 
>>> I’ve never seen this cause any actual confusion, nor has anyone I know who 
>>> teaches/develops these sorts of tools. As far as I can tell, the broader 
>>> programming community is rapidly converging on this as standard terminology:
>>> 
>>> * Gemfile.lock (Ruby)
>>> * Cargo.lock (Rust)
>>> * Composer.lock (PHP)
>>> * yarn.lock (JS)
>>> * pubspec.lock (Dart)
>>> * Podfile.lock (Swift/Objc!)
>>> 
>>> Diverging from this seems counter-productive.
 Philosophy
 
 Our philosophy with regard to pinning is that we actively want to 
 encourage packages to develop against the latest semantically appropriate 
 versions of their dependencies, in order to foster rapid development 
 amongst the 

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Huon Wilson via swift-evolution]

> On Oct 14, 2016, at 09:43, Alexis via swift-evolution 
>  wrote:
> 
> A library shouldn’t pin its dependencies, while an application should.

Not only “shouldn’t” but can’t: Rust’s cargo (I don’t know for sure about 
Bundler and Yarn, but they’re all in the same vein, and pretty much from the 
same person) will just ignore any non-top-level lock files, i.e. the package 
that user is working on has a record of the exact versions of everything in 
their dependency graph, and the user can update all or just parts of that graph 
fairly precisely, as desired.

My impression is that other ecosystems without pinning-by-default have 
seriously suffered from the lack of reliable reproducible builds. For instance, 
a major complaint I have seen about "go get” is that one can come back to some 
code after a few months to fix a minor bug and have no chance of getting the 
code to compile, basically just requiring a full rewrite, because dependencies' 
code has changed (or disappeared entirely) and there’s no record of what the 
original was, despite your code being completely untouched in all that time. Of 
course, a hard push towards API-level semantic versioning may allay the worst 
of the code-changing problems, but unless there’s going to be some seriously 
fancy static analysis (something something halting problem), there will be a 
lot of breaking changes that can’t be picked up.

---

To reframe the discussion slightly, not pinning dependencies effectively means 
that the tools are making “random" changes to your code outside your control. 
Sure, those changes were transitively made by possibly-computer-assisted humans 
and may fix bugs, but those pesky meat-bags can still make mistakes, and, they 
don’t see the interactions between all the different packages in your specific 
application.

IME having the predictability of “never changing code under my feet” combined 
with pervasive semantic versioning hits an empowering middle ground of being 
able to depend on many & varied packages and update them to the latest versions 
without fear (for one, it’s easy to revert the lock file if something breaks 
during an update). Feedback from others about cargo is the same, often along 
the lines of “it’s the best package manager I’ve ever used”.

Also, more on the side of implementation details, having a lock file by default 
probably mean one can (get closer to) never hitting the network unless the user 
asks for it, making working offline or on a low-speed/high-latency connection 
easier, i.e. no need to check for new versions of the whole dependency graph on 
O(every) build, which aggressively keeping everything up to date would 
seemingly have to do? (I don’t know swift-pm’s current behavior here, so maybe 
there’s some tricks that avoid it.)

Huon___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Max Desiatov via swift-evolution]

The other point is that when working in a multi-language environment, having 
conventions such as this broken causes additional mental burden. That is, after 
working with JavaScript/Rust/iOS with CocoaPods and then switching to Swift, 
would require a lot of unneeded context switching, as in: "Where's that 
lockfile? I can't find it. Oh great, turns out it's not a lockfile, it's 
something else".

With best regards, Max.

> On 14 Oct 2016, at 17:59, Max Desiatov  wrote:
> 
> I also agree with the point that .lock extension better suits here and 
> adheres to a convention already established in other languages. I personally 
> would prefer the file to be named Package.lock, not Package.pins and also 
> think that it would help newcomers who already used other package managers, 
> especially CocoaPods.
> 
> With best regards, Max.
> 
>> On 14 Oct 2016, at 17:43, Alexis via swift-evolution 
>> > wrote:
>> 
>> 
>> 
>>> On Oct 14, 2016, at 2:01 AM, Ankit Aggarwal via swift-evolution 
>>> > wrote:
>>> 
>>> Hi,
>>> 
>>> We're proposing version pinning feature in Swift Package Manager. The 
>>> proposal is available here 
>>> 
>>>  and also in this email:
>>> 
>>> Feedback welcomed!
>>> 
>>> Thanks,
>>> Ankit
>>> 
>>> 
>>> 
>>> Package Manager Version Pinning
>>> Proposal: SE-
>>> Author: Daniel Dunbar , Ankit Aggarwal 
>>> 
>>> Review Manager: TBD
>>> Status: Discussion
>>> Introduction
>>> This is a proposal for adding package manager features to "pin" or "lock" 
>>> package dependencies to particular versions.
>>> 
>>> Motivation
>>> As used in this proposal, version pinning refers to the practice of 
>>> controlling exactly which specific version of a dependency is selected by 
>>> the dependency resolution algorithm, independent from the semantic 
>>> versioning specification. Thus, it is a way of instructing the package 
>>> manager to select a particular version from among all of the versions of a 
>>> package which could be chosen while honoring the dependency constraints.
>>> 
>>> Terminology
>>> 
>>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>>> since the term "lock" is already overloaded between POSIX file locks and 
>>> locks in concurrent programming.
>>> 
>> I’ve never seen this cause any actual confusion, nor has anyone I know who 
>> teaches/develops these sorts of tools. As far as I can tell, the broader 
>> programming community is rapidly converging on this as standard terminology:
>> 
>> * Gemfile.lock (Ruby)
>> * Cargo.lock (Rust)
>> * Composer.lock (PHP)
>> * yarn.lock (JS)
>> * pubspec.lock (Dart)
>> * Podfile.lock (Swift/Objc!)
>> 
>> Diverging from this seems counter-productive.
>>> Philosophy
>>> 
>>> Our philosophy with regard to pinning is that we actively want to encourage 
>>> packages to develop against the latest semantically appropriate versions of 
>>> their dependencies, in order to foster rapid development amongst the 
>>> ecosystem and strong reliance on the semantic versioning concept. Our 
>>> design for version pinning is thus intended to be a feature for package 
>>> authors and users to use in crafting specific workflows, not be a mechanism 
>>> by which most of the packages in the ecosystem pin themselves to specific 
>>> versions of each other.
>>> 
>>> Use Cases
>>> 
>>> Our proposal is designed to satisfy several different use cases for such a 
>>> behavior:
>>> 
>>> Standardizing team workflows
>>> 
>>> When collaborating on a package, it can be valuable for team members (and 
>>> continuous integration) to all know they are using the same exact version 
>>> of dependencies, to avoid "works for me" situations.
>>> 
>>> This can be particularly important for certain kinds of open source 
>>> projects which are actively being cloned by new users, and which want to 
>>> have some measure of control around exactly which available version of a 
>>> dependency is selected.
>>> 
>>> Difficult to test packages or dependencies
>>> 
>>> Complex packages which have dependencies which may be hard to test, or hard 
>>> to analyze when they break, may choose to maintain careful control over 
>>> what versions of their upstream dependencies they recommend -- even if 
>>> conceptually they regularly update those recommendations following the true 
>>> semantic version specification of the dependency.
>>> 
>>> Dependency locking w.r.t. deployment
>>> 
>>> When stabilizing a release for deployment, or building a version of a 
>>> package for deployment, it is important to be able to lock down the exact 
>>> versions of dependencies in use, so that the resulting product can be 
>>> exactly recreated later if necessary.
>>> 
>>> 

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Max Desiatov via swift-evolution]

I also agree with the point that .lock extension better suits here and adheres 
to a convention already established in other languages. I personally would 
prefer the file to be named Package.lock, not Package.pins and also think that 
it would help newcomers who already used other package managers, especially 
CocoaPods.

With best regards, Max.

> On 14 Oct 2016, at 17:43, Alexis via swift-evolution 
>  wrote:
> 
> 
> 
>> On Oct 14, 2016, at 2:01 AM, Ankit Aggarwal via swift-evolution 
>> > wrote:
>> 
>> Hi,
>> 
>> We're proposing version pinning feature in Swift Package Manager. The 
>> proposal is available here 
>> 
>>  and also in this email:
>> 
>> Feedback welcomed!
>> 
>> Thanks,
>> Ankit
>> 
>> 
>> 
>> Package Manager Version Pinning
>> Proposal: SE-
>> Author: Daniel Dunbar , Ankit Aggarwal 
>> 
>> Review Manager: TBD
>> Status: Discussion
>> Introduction
>> This is a proposal for adding package manager features to "pin" or "lock" 
>> package dependencies to particular versions.
>> 
>> Motivation
>> As used in this proposal, version pinning refers to the practice of 
>> controlling exactly which specific version of a dependency is selected by 
>> the dependency resolution algorithm, independent from the semantic 
>> versioning specification. Thus, it is a way of instructing the package 
>> manager to select a particular version from among all of the versions of a 
>> package which could be chosen while honoring the dependency constraints.
>> 
>> Terminology
>> 
>> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
>> since the term "lock" is already overloaded between POSIX file locks and 
>> locks in concurrent programming.
>> 
> I’ve never seen this cause any actual confusion, nor has anyone I know who 
> teaches/develops these sorts of tools. As far as I can tell, the broader 
> programming community is rapidly converging on this as standard terminology:
> 
> * Gemfile.lock (Ruby)
> * Cargo.lock (Rust)
> * Composer.lock (PHP)
> * yarn.lock (JS)
> * pubspec.lock (Dart)
> * Podfile.lock (Swift/Objc!)
> 
> Diverging from this seems counter-productive.
>> Philosophy
>> 
>> Our philosophy with regard to pinning is that we actively want to encourage 
>> packages to develop against the latest semantically appropriate versions of 
>> their dependencies, in order to foster rapid development amongst the 
>> ecosystem and strong reliance on the semantic versioning concept. Our design 
>> for version pinning is thus intended to be a feature for package authors and 
>> users to use in crafting specific workflows, not be a mechanism by which 
>> most of the packages in the ecosystem pin themselves to specific versions of 
>> each other.
>> 
>> Use Cases
>> 
>> Our proposal is designed to satisfy several different use cases for such a 
>> behavior:
>> 
>> Standardizing team workflows
>> 
>> When collaborating on a package, it can be valuable for team members (and 
>> continuous integration) to all know they are using the same exact version of 
>> dependencies, to avoid "works for me" situations.
>> 
>> This can be particularly important for certain kinds of open source projects 
>> which are actively being cloned by new users, and which want to have some 
>> measure of control around exactly which available version of a dependency is 
>> selected.
>> 
>> Difficult to test packages or dependencies
>> 
>> Complex packages which have dependencies which may be hard to test, or hard 
>> to analyze when they break, may choose to maintain careful control over what 
>> versions of their upstream dependencies they recommend -- even if 
>> conceptually they regularly update those recommendations following the true 
>> semantic version specification of the dependency.
>> 
>> Dependency locking w.r.t. deployment
>> 
>> When stabilizing a release for deployment, or building a version of a 
>> package for deployment, it is important to be able to lock down the exact 
>> versions of dependencies in use, so that the resulting product can be 
>> exactly recreated later if necessary.
>> 
>> Proposed solution
>> We will introduce support for an optional new file Package.pins adjacent to 
>> the Package.swift manifest, called the "pins file". We will also introduce a 
>> number of new commands (see below) for maintaining the pins file.
>> 
>> This file will record the active version pin information for the package, 
>> including data such as the package identifier, the pinned version, and 
>> explicit information on the pinned version (e.g., the commit hash/SHA for 
>> the resolved tag).
>> 
>> The exact file format is unspecified/implementation defined, however, in 
>> practice it will be a JSON data file.
>> 
>> This file may be checked 

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Alexis via swift-evolution]

> On Oct 14, 2016, at 2:01 AM, Ankit Aggarwal via swift-evolution 
>  wrote:
> 
> Hi,
> 
> We're proposing version pinning feature in Swift Package Manager. The 
> proposal is available here 
> 
>  and also in this email:
> 
> Feedback welcomed!
> 
> Thanks,
> Ankit
> 
> 
> 
> Package Manager Version Pinning
> Proposal: SE-
> Author: Daniel Dunbar , Ankit Aggarwal 
> 
> Review Manager: TBD
> Status: Discussion
> Introduction
> This is a proposal for adding package manager features to "pin" or "lock" 
> package dependencies to particular versions.
> 
> Motivation
> As used in this proposal, version pinning refers to the practice of 
> controlling exactly which specific version of a dependency is selected by the 
> dependency resolution algorithm, independent from the semantic versioning 
> specification. Thus, it is a way of instructing the package manager to select 
> a particular version from among all of the versions of a package which could 
> be chosen while honoring the dependency constraints.
> 
> Terminology
> 
> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
> since the term "lock" is already overloaded between POSIX file locks and 
> locks in concurrent programming.
> 
I’ve never seen this cause any actual confusion, nor has anyone I know who 
teaches/develops these sorts of tools. As far as I can tell, the broader 
programming community is rapidly converging on this as standard terminology:

* Gemfile.lock (Ruby)
* Cargo.lock (Rust)
* Composer.lock (PHP)
* yarn.lock (JS)
* pubspec.lock (Dart)
* Podfile.lock (Swift/Objc!)

Diverging from this seems counter-productive.
> Philosophy
> 
> Our philosophy with regard to pinning is that we actively want to encourage 
> packages to develop against the latest semantically appropriate versions of 
> their dependencies, in order to foster rapid development amongst the 
> ecosystem and strong reliance on the semantic versioning concept. Our design 
> for version pinning is thus intended to be a feature for package authors and 
> users to use in crafting specific workflows, not be a mechanism by which most 
> of the packages in the ecosystem pin themselves to specific versions of each 
> other.
> 
> Use Cases
> 
> Our proposal is designed to satisfy several different use cases for such a 
> behavior:
> 
> Standardizing team workflows
> 
> When collaborating on a package, it can be valuable for team members (and 
> continuous integration) to all know they are using the same exact version of 
> dependencies, to avoid "works for me" situations.
> 
> This can be particularly important for certain kinds of open source projects 
> which are actively being cloned by new users, and which want to have some 
> measure of control around exactly which available version of a dependency is 
> selected.
> 
> Difficult to test packages or dependencies
> 
> Complex packages which have dependencies which may be hard to test, or hard 
> to analyze when they break, may choose to maintain careful control over what 
> versions of their upstream dependencies they recommend -- even if 
> conceptually they regularly update those recommendations following the true 
> semantic version specification of the dependency.
> 
> Dependency locking w.r.t. deployment
> 
> When stabilizing a release for deployment, or building a version of a package 
> for deployment, it is important to be able to lock down the exact versions of 
> dependencies in use, so that the resulting product can be exactly recreated 
> later if necessary.
> 
> Proposed solution
> We will introduce support for an optional new file Package.pins adjacent to 
> the Package.swift manifest, called the "pins file". We will also introduce a 
> number of new commands (see below) for maintaining the pins file.
> 
> This file will record the active version pin information for the package, 
> including data such as the package identifier, the pinned version, and 
> explicit information on the pinned version (e.g., the commit hash/SHA for the 
> resolved tag).
> 
> The exact file format is unspecified/implementation defined, however, in 
> practice it will be a JSON data file.
> 
> This file may be checked into SCM by the user, so that its effects apply to 
> all users of the package. However, it may also be maintained only locally 
> (e.g., placed in the .gitignore file). We intend to leave it to package 
> authors to decide which use case is best for their project.
> 
> In the presence of a Package.pins file, the package manager will respect the 
> pinned dependencies recorded in the file whenever it needs to do dependency 
> resolution (e.g., on the initial checkout or when updating).
> 
> The pins file will not override Manifest specified version requirements and 
> it will be an error (with proper 

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Daniel Dunbar via swift-evolution]

Let's not change this thread into a discussion of English. :)

 - Daniel

> On Oct 14, 2016, at 8:54 AM, Daniel Duan via swift-evolution 
>  wrote:
> 
> Fyi, not my idea: 
> https://github.com/apple/swift-evolution/commit/51d93875b25ba122a6417fdc5216ee94c6e7ee9e
>  
> 
> 
> Daniel Duan
> Sent from my iPhone
> 
> On Oct 14, 2016, at 7:14 AM, Goffredo Marocchi  > wrote:
> 
>> Let's not promote this idea English has comprehensible and easy to refer to 
>> pronunciation rules ;). It needs reforming :P, but let's keep it for 
>> English-Evolution ;).
>> 
>> Sent from my iPhone
>> 
>>> On 14 Oct 2016, at 13:42, Haravikk via swift-evolution 
>>> > wrote:
>>> 
>>> 
 On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
 > wrote:
 
 1. “honor” is mis-spelled in “weird queen’s dialect”.
>>> 
>>> I'm sorry, but I throw an exception at this; when you say "weird queen's 
>>> dialect" do you mean… English? I don't go around referring to the other 
>>> variation as "weird can't spell dialect" (but maybe I should) 
>>> The u in words like honour is what makes it pronounced like "onner" rather 
>>> than "hone-ore", same with colour being "culler" rather than "coal-ore". 
>>> Sorry but it really annoys me when people consider the English version of 
>>> English to be the weird one, as the clue is literally in the name as to 
>>> which version is correct. This is why it still galls me that the language 
>>> in macOS is "British English" yet the other one is just "English" rather 
>>> than "American English" or whatever, it's a hideous double standard.
>>> 
>>> 
>>> That aside, I'm a strong +1 for the feature 
>>> ___
>>> swift-evolution mailing list
>>> swift-evolution@swift.org 
>>> https://lists.swift.org/mailman/listinfo/swift-evolution 
>>> 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Daniel Duan via swift-evolution]

Fyi, not my idea: 
https://github.com/apple/swift-evolution/commit/51d93875b25ba122a6417fdc5216ee94c6e7ee9e

Daniel Duan
Sent from my iPhone

> On Oct 14, 2016, at 7:14 AM, Goffredo Marocchi  wrote:
> 
> Let's not promote this idea English has comprehensible and easy to refer to 
> pronunciation rules ;). It needs reforming :P, but let's keep it for 
> English-Evolution ;).
> 
> Sent from my iPhone
> 
>> On 14 Oct 2016, at 13:42, Haravikk via swift-evolution 
>>  wrote:
>> 
>> 
>>> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
>>>  wrote:
>>> 
>>> 1. “honor” is mis-spelled in “weird queen’s dialect”.
>> 
>> I'm sorry, but I throw an exception at this; when you say "weird queen's 
>> dialect" do you mean… English? I don't go around referring to the other 
>> variation as "weird can't spell dialect" (but maybe I should) 
>> The u in words like honour is what makes it pronounced like "onner" rather 
>> than "hone-ore", same with colour being "culler" rather than "coal-ore". 
>> Sorry but it really annoys me when people consider the English version of 
>> English to be the weird one, as the clue is literally in the name as to 
>> which version is correct. This is why it still galls me that the language in 
>> macOS is "British English" yet the other one is just "English" rather than 
>> "American English" or whatever, it's a hideous double standard.
>> 
>> 
>> That aside, I'm a strong +1 for the feature 
>> ___
>> swift-evolution mailing list
>> swift-evolution@swift.org
>> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Benjamin Spratling via swift-evolution]

> Let's not promote this idea English has comprehensible and easy to refer to 
> pronunciation rules ;). It needs reforming :P, but let's keep it for 
> English-Evolution ;).


+1
  Can you get me on that list?  I have a long list of bugs to report. :)
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Goffredo Marocchi via swift-evolution]

Let's not promote this idea English has comprehensible and easy to refer to 
pronunciation rules ;). It needs reforming :P, but let's keep it for 
English-Evolution ;).

Sent from my iPhone

> On 14 Oct 2016, at 13:42, Haravikk via swift-evolution 
>  wrote:
> 
> 
>> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
>>  wrote:
>> 
>> 1. “honor” is mis-spelled in “weird queen’s dialect”.
> 
> I'm sorry, but I throw an exception at this; when you say "weird queen's 
> dialect" do you mean… English? I don't go around referring to the other 
> variation as "weird can't spell dialect" (but maybe I should) 
> The u in words like honour is what makes it pronounced like "onner" rather 
> than "hone-ore", same with colour being "culler" rather than "coal-ore". 
> Sorry but it really annoys me when people consider the English version of 
> English to be the weird one, as the clue is literally in the name as to which 
> version is correct. This is why it still galls me that the language in macOS 
> is "British English" yet the other one is just "English" rather than 
> "American English" or whatever, it's a hideous double standard.
> 
> 
> That aside, I'm a strong +1 for the feature 
> ___
> swift-evolution mailing list
> swift-evolution@swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Haravikk via swift-evolution]

> On 14 Oct 2016, at 07:16, Daniel Duan via swift-evolution 
>  wrote:
> 
> 1. “honor” is mis-spelled in “weird queen’s dialect”.

I'm sorry, but I throw an exception at this; when you say "weird queen's 
dialect" do you mean… English? I don't go around referring to the other 
variation as "weird can't spell dialect" (but maybe I should) 
The u in words like honour is what makes it pronounced like "onner" rather than 
"hone-ore", same with colour being "culler" rather than "coal-ore". Sorry but 
it really annoys me when people consider the English version of English to be 
the weird one, as the clue is literally in the name as to which version is 
correct. This is why it still galls me that the language in macOS is "British 
English" yet the other one is just "English" rather than "American English" or 
whatever, it's a hideous double standard.


That aside, I'm a strong +1 for the feature 
___
swift-evolution mailing list
swift-evolution@swift.org
https://lists.swift.org/mailman/listinfo/swift-evolution

Re: [swift-evolution] Proposal: Package Manager Version Pinning

[Daniel Duan via swift-evolution]

This is a familiar feature among package managers and has been proven useful in 
practice. Two points regarding the proposed text:

1. “honor” is mis-spelled in “weird queen’s dialect”.
2. SHA/man-in-the-middle attack section needs either more detailed 
explanation/reference materials, or shouldn’t be included at all (assuming when 
the hash feature gets introduced, there’d be another proposal for it).

Overall strong +1.
> On Oct 13, 2016, at 11:01 PM, Ankit Aggarwal via swift-evolution 
>  wrote:
> 
> Hi,
> 
> We're proposing version pinning feature in Swift Package Manager. The 
> proposal is available here 
> 
>  and also in this email:
> 
> Feedback welcomed!
> 
> Thanks,
> Ankit
> 
> 
> 
> Package Manager Version Pinning
> Proposal: SE-
> Author: Daniel Dunbar , Ankit Aggarwal 
> 
> Review Manager: TBD
> Status: Discussion
> Introduction
> This is a proposal for adding package manager features to "pin" or "lock" 
> package dependencies to particular versions.
> 
> Motivation
> As used in this proposal, version pinning refers to the practice of 
> controlling exactly which specific version of a dependency is selected by the 
> dependency resolution algorithm, independent from the semantic versioning 
> specification. Thus, it is a way of instructing the package manager to select 
> a particular version from among all of the versions of a package which could 
> be chosen while honoring the dependency constraints.
> 
> Terminology
> 
> We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
> since the term "lock" is already overloaded between POSIX file locks and 
> locks in concurrent programming.
> 
> Philosophy
> 
> Our philosophy with regard to pinning is that we actively want to encourage 
> packages to develop against the latest semantically appropriate versions of 
> their dependencies, in order to foster rapid development amongst the 
> ecosystem and strong reliance on the semantic versioning concept. Our design 
> for version pinning is thus intended to be a feature for package authors and 
> users to use in crafting specific workflows, not be a mechanism by which most 
> of the packages in the ecosystem pin themselves to specific versions of each 
> other.
> 
> Use Cases
> 
> Our proposal is designed to satisfy several different use cases for such a 
> behavior:
> 
> Standardizing team workflows
> 
> When collaborating on a package, it can be valuable for team members (and 
> continuous integration) to all know they are using the same exact version of 
> dependencies, to avoid "works for me" situations.
> 
> This can be particularly important for certain kinds of open source projects 
> which are actively being cloned by new users, and which want to have some 
> measure of control around exactly which available version of a dependency is 
> selected.
> 
> Difficult to test packages or dependencies
> 
> Complex packages which have dependencies which may be hard to test, or hard 
> to analyze when they break, may choose to maintain careful control over what 
> versions of their upstream dependencies they recommend -- even if 
> conceptually they regularly update those recommendations following the true 
> semantic version specification of the dependency.
> 
> Dependency locking w.r.t. deployment
> 
> When stabilizing a release for deployment, or building a version of a package 
> for deployment, it is important to be able to lock down the exact versions of 
> dependencies in use, so that the resulting product can be exactly recreated 
> later if necessary.
> 
> Proposed solution
> We will introduce support for an optional new file Package.pins adjacent to 
> the Package.swift manifest, called the "pins file". We will also introduce a 
> number of new commands (see below) for maintaining the pins file.
> 
> This file will record the active version pin information for the package, 
> including data such as the package identifier, the pinned version, and 
> explicit information on the pinned version (e.g., the commit hash/SHA for the 
> resolved tag).
> 
> The exact file format is unspecified/implementation defined, however, in 
> practice it will be a JSON data file.
> 
> This file may be checked into SCM by the user, so that its effects apply to 
> all users of the package. However, it may also be maintained only locally 
> (e.g., placed in the .gitignore file). We intend to leave it to package 
> authors to decide which use case is best for their project.
> 
> In the presence of a Package.pins file, the package manager will respect the 
> pinned dependencies recorded in the file whenever it needs to do dependency 
> resolution (e.g., on the initial checkout or when updating).
> 
> The pins file will not override Manifest specified version requirements and 
> it will be an 

[swift-evolution] Proposal: Package Manager Version Pinning

[Ankit Aggarwal via swift-evolution]

Hi,

We're proposing version pinning feature in Swift Package Manager. The proposal 
is available here 

 and also in this email:

Feedback welcomed!

Thanks,
Ankit



Package Manager Version Pinning
Proposal: SE-
Author: Daniel Dunbar , Ankit Aggarwal 

Review Manager: TBD
Status: Discussion
Introduction
This is a proposal for adding package manager features to "pin" or "lock" 
package dependencies to particular versions.

Motivation
As used in this proposal, version pinning refers to the practice of controlling 
exactly which specific version of a dependency is selected by the dependency 
resolution algorithm, independent from the semantic versioning specification. 
Thus, it is a way of instructing the package manager to select a particular 
version from among all of the versions of a package which could be chosen while 
honoring the dependency constraints.

Terminology

We have chosen to use "pinning" to refer to this feature, over "lockfiles", 
since the term "lock" is already overloaded between POSIX file locks and locks 
in concurrent programming.

Philosophy

Our philosophy with regard to pinning is that we actively want to encourage 
packages to develop against the latest semantically appropriate versions of 
their dependencies, in order to foster rapid development amongst the ecosystem 
and strong reliance on the semantic versioning concept. Our design for version 
pinning is thus intended to be a feature for package authors and users to use 
in crafting specific workflows, not be a mechanism by which most of the 
packages in the ecosystem pin themselves to specific versions of each other.

Use Cases

Our proposal is designed to satisfy several different use cases for such a 
behavior:

Standardizing team workflows

When collaborating on a package, it can be valuable for team members (and 
continuous integration) to all know they are using the same exact version of 
dependencies, to avoid "works for me" situations.

This can be particularly important for certain kinds of open source projects 
which are actively being cloned by new users, and which want to have some 
measure of control around exactly which available version of a dependency is 
selected.

Difficult to test packages or dependencies

Complex packages which have dependencies which may be hard to test, or hard to 
analyze when they break, may choose to maintain careful control over what 
versions of their upstream dependencies they recommend -- even if conceptually 
they regularly update those recommendations following the true semantic version 
specification of the dependency.

Dependency locking w.r.t. deployment

When stabilizing a release for deployment, or building a version of a package 
for deployment, it is important to be able to lock down the exact versions of 
dependencies in use, so that the resulting product can be exactly recreated 
later if necessary.

Proposed solution
We will introduce support for an optional new file Package.pins adjacent to the 
Package.swift manifest, called the "pins file". We will also introduce a number 
of new commands (see below) for maintaining the pins file.

This file will record the active version pin information for the package, 
including data such as the package identifier, the pinned version, and explicit 
information on the pinned version (e.g., the commit hash/SHA for the resolved 
tag).

The exact file format is unspecified/implementation defined, however, in 
practice it will be a JSON data file.

This file may be checked into SCM by the user, so that its effects apply to all 
users of the package. However, it may also be maintained only locally (e.g., 
placed in the .gitignore file). We intend to leave it to package authors to 
decide which use case is best for their project.

In the presence of a Package.pins file, the package manager will respect the 
pinned dependencies recorded in the file whenever it needs to do dependency 
resolution (e.g., on the initial checkout or when updating).

The pins file will not override Manifest specified version requirements and it 
will be an error (with proper diagnostics) if there is a conflict between the 
pins and the manifest specification.

Detailed Design
We will add a new command pin to swift package tool with following semantics:

$ swift package pin ( [--all] | [] [] ) [--message 
]
The package-name refers to the name of the package as specified in its manifest.

This command pins one or all dependencies. The command which pins a single 
version can optionally take a specific version to pin to, if unspecified (or 
with --all) the behaviour is to pin to the current package version in use. 
Examples: 

$ swift package pin --all - pins all the dependencies.
$ swift package pin Foo - pins Foo at current resolved version.
$ swift package pin Foo 1.2.3 - pins Foo at