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-...@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 

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

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 

@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 

 - Daniel

swift-evolution mailing list

Reply via email to