>
> * What is your evaluation of the proposal?
+1
> * Is the problem being addressed significant enough to warrant a change
> to Swift?
Yes, version pinning is very important to dependency management in production
environments.
> * Does this proposal fit well with the feel and direction of Swift?
Yes.
> * If you have used other languages or libraries with a similar feature,
> how do you feel that this proposal compares to those?
I have used various dependency management systems and had seen some evolving in
particular domains (pip’s eventual emergence over the last decade in Python
land comes to mind. Linux package managers as found in
Debian/CentOS/Arch/Gentoo, albeit less analogous here). Ruby gems, Cocoapods
and Carthage are the ones I’m using in production today.
Excluding a few cosmetic differences (.pins extensions, whether to
automatically pin, pinning commands etc), the proposed mechanisms are actually
very similar to the ones we know and love in iOS/macOS development today:
there’s some remote sources where the dependencies reside, most likely version
controlled repositories with explicit ways to identify a certain state in their
history. Using a text file to record the state identifiers, the manager can
ensure shared, reproducible building environment. No surprise here.
As for the difference: I can’t recall a time when I really thought about the
file extension of Podfile.lock or Carthage.resolved or Gems.WhatEverTheHeck.
The proposal had dedicated a good potion to explain the choice of .pins, that
deserves some extra credit IMHO. Explicit pinning commands gives us more
control. In a team environment, if you are using a pinning feature, it’s
*really* annoying to have accidentally triggers a change in the .lock/.resolved
files. This is happens when your team opt-out a latest version of the
dependency. Automatic pinning, therefore, is not a feature, it’s the lack of
one.
> * How much effort did you put into your review? A glance, a quick
> reading, or an in-depth study?
>
Read initial draft of the proposal and its discussions. Read the actual
proposal.
_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution
