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>
>> I particularly like Yehuda Katz's explanation on why it works this way:
> 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
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
swift-evolution mailing list