[swift-build-dev] [swift-evolution] Proposal: Package Manager Version Pinning

[Daniel Dunbar]

I'm replying here as a proxy for a bunch of other messages, since it is the latest one when I started typing. :)

> On Oct 14, 2016, at 12:40 PM, Ryan Lovelett <swift-dev at ryan.lovelett.me> wrote:
> 
>> I particularly like Yehuda Katz's explanation on why it works this way: https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537 <https://github.com/yarnpkg/yarn/issues/838#issuecomment-253362537> 
> 
> This was a powerful description for me. @Rob thank you for providing that!
> 
> The articulation of the purpose/philosophy behind the whole thing was really clear and made sense to me. Even though I've never used Rust or Cargo. Nor have I ever run into any problems with npm such that I would prefer yarn over it. I've used Bundler for years and love it.
> Yehuda Katz has been involved in making 3 different package managers for 3 different communities/languages over at least a 6-year span. It feels trite but it seems likely he has knowledge/experience we might not. It might be wise to seriously consider the wisdom of others with experience.
> 
> I will say that like others on this thread prefer determinism in my builds.
> 
> Whatever path leads me there is the path I want to walk. I'm not smart enough to say if this proposal will preclude that or not. I am moved by the notion that there are successful package managers out there as examples which today achieve that goal. 

Alexis, Huon and I just had an in person conversation about this thread, and I wanted to post a summary:

1. I think there is some confusion in the thread based on us not describing in the proposal exactly how the package manager *behaves today*, and the parts which we expected to be unchanged.

We effectively "pin locally" today, in the sense that we *never* update a dependency without the users involvement, and we all agree we should never ever ever ever do this. I don't personally understand how any tool would ever not do this, so I may have skipped over clarifying this. I'm not sure if there was confusion on this point, but if so, hopefully that helps.

We also give you a way to "see" what you are pinned at with `swift package show-dependencies`.

What this proposal about is in one sense being able to export and share those pins.

2. Huon, Alexis, and I all agree we should never *inherit* pins by default.

3. Huon pointed out using "shared" to mean "package intended to be used as a dependency" isn't correct, since one might often share a package intended to just be built and used as a command line tool. OTOH, I personally don't care for library vs executable since executables can often be used as dependencies for server-side stuff, or as build tools.

4. We also all agree that there are effectively two very different workflows based on whether a package is intended to be a dependency.

We have three very interesting ecosystems:
	A. Using packages as macOS/iOS/etc app dependencies.
	B. Using packages for server-side Swift code.
	C. Using packages to directly build command line tools and applications you can install.

In (A), all packages are dependencies, so our emphasis is on workflows oriented towards that.

In (B), we expect somewhat more sophistication around management of the pin file (w.r.t. PaaS deployment, continuous delivery, etc.), and so Huon and I at least agreed it was somewhat irrelevant. Also, we expect that more people developing in this space will simultaneously be factoring out packages which are intended to be dependencies.

In (C), by definition the most interesting and heavily used (as in installed) packages are *not* generally dependencies.

Today, (A) is a huge focus, and (B) is the main current consumer of SwiftPM. (C) is very interesting, and many of us would love to us it, but the reality is I don't see many people doing development in this space versus simply publishing via Homebrew, etc. Given that, my position is that *most* of the ecosystem is oriented towards packages which are intended to be dependencies, and we should choose our defaults accordingly.

5. Given that many people agree there are two workflows (we ourselves had talked about this a lot when writing the proposal, but didn't put it in), we felt it makes sense to consider adding that as an explicit declaration *somewhere*.

@Eloy, @Orta: Suppose we had a semantic notion of which packages were intended to be "top-level" versus used as a dependency, and we chose our defaults accordingly (in this case, we would orient workflows towards pinning by default in the top-level case, in the used as a dependency case we would orient away from it, e.g. warning you if you checked it in). What would you think of such a design?

 - Daniel

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-build-dev/attachments/20161014/cb96dcb7/attachment.html>