Thank you, Daniel. I have marked the SE-0145 as such in the swift-evolution repository.
Anders > On 2016-11-10, at 09.41, Daniel Dunbar <[email protected]> wrote: > > Thanks to everyone who participated in this review! > > Based on the pretty universal negative feedback, we are going to reject this > proposal as is, and take it back for another round of revisions. > > Our revised plan is: > 1. To introduce an "autopin" behavior to cover the problem Paul outlined > where `pin --all` effectively needs to be "sticky" for any new dependencies > which come into play. > 2. To make auto pinning on by default, with an explicit mechanism for > projects to opt out. > > I hope to have this written up for review next week. > > Thanks! > - Daniel > >> On Nov 4, 2016, at 9:06 AM, Paul Cantrell via swift-evolution >> <[email protected] <mailto:[email protected]>> wrote: >> >> What is your evaluation of the proposal? >> >> General +1, with reservations. Novel elements of the proposed behavior will >> need careful evaluation and refinement as we see how they plays out in >> practice, with open-mindedness from both users and the core team. >> >> Breaking it down: >> >> +1 on having this feature in some form. It’s essential. >> >> +1 on making user choice about .gitignore the thing that controls whether >> and how pinning is shared within a team. That’s simple, clear, accommodates >> a wide range of needs, and is consistent with other package managers. >> >> +1 that pinfiles have no effect whatsoever on dependent projects. That’s the >> only sensible way for it to work, but since there was some debate about >> that, I’ll just reiterate support. >> >> -1 on making dependencies unpinned by default. Trying to induce unexpected >> behavior to encourage testing can be a good technique — in contexts where >> testing is the goal. My gut tells me that doing this when building is the >> goal will cause a lot of confusion and kvetching. I follow the proposal’s >> argument that unexpected breakages are a nice way to make strict semver a >> community norm … and I just do not buy it. >> >> However, given that we hashed this out at great length and the core team is >> still enamored of the idea, I’m willing to give it a try! I’d love to be >> proved wrong. >> >> +1 on the proposed command structure given that I’ve lost the aforementioned >> “always pin” argument. Living in a sometimes-pinned-sometimes-not world is >> going to be confusing, but the proposed commands help as best they can. >> >> ¿-1? This is a big one. If I do: >> >> swift package pin --all >> >> …and then add a new dependency, is the new dependency also pinned? It should >> be. To pin or not to pin is typically a project- and team-wide policy >> decision. I do see the use case for pinning just one ill-behaved dependency, >> but more typically pinning is something that is built in to a team’s testing >> process and their assumptions about a whole build’s behavior. >> >> The proposal is vague on this point, but could be interpreted to mean that >> --all does not pin new dependencies: “Dependencies are never automatically >> pinned, pinning is only ever taken as a result of an explicit user action.” >> (Aside: there should be a semicolon instead of a comma in that sentence.) I >> assume — hope — that this is not the case! If --all does not affect new >> dependencies, then I’m -1 on the proposal. >> >> ¿-1? The proposal mentions that SwiftPM already effectively performs local >> pinning, but is ambiguous about whether this behavior remains separate from >> the new pinfile. I’m dubious about having two separate pinning mechanisms, >> one visible and one invisible. >> >> +1 to the proposal’s repeated mentions of clear output and helpful >> diagnostics. Since this proposal introduces behavior that’s somewhat off the >> beaten path for package managers, this will be essential. >> >> On the pin/lock controversy >> >> I don’t care. Computer science is full of heavily overloaded terms where a >> loose underlying concept takes on radically different meanings (bridge, >> channel, dispatch, edge, graph, header, key, model, module, node, open, >> parameter, port, process, protocol, query, return, row, source, union). We >> do just fine disambiguating all these in context, thank you very much. >> Renaming “lock” to “pin” solves a problem that doesn’t exist. >> >> However, we programmers are _also_ used to dealing with synonyms or >> partially overlapping near-synonyms (nil / null; closure / lambda / block; >> field / instance variable; tagged union / associated type enum; etc) and we >> also do just fine with those too. I’m sure we’ll learn to deal with lock / >> pin, and nobody will care after 6 months. >> >> In short, “pin” is an unobjectionable solution to a non-problem. Core team >> is excited about “pin?” Grand. It’s a fine term. Do it and move on. >> >> >> Is the problem being addressed significant enough to warrant a change to >> Swift? >> >> It’s essential. SwiftPM will be impractical in many real-world situations >> until this is sorted out. >> >> >> Does this proposal fit well with the feel and direction of Swift? >> >> Yes, it’s consistent with the general approach of SwiftPM. >> >> >> If you have used other languages or libraries with a similar feature, how do >> you feel that this proposal compares to those? >> >> I’ve used bundler, Carthage, and CocoaPods extensively. All of them always >> generate a lockfile (Gemfile.lock, Cartfile.resolved, and Podfile.lock). All >> of them use these files as the unique mechanism for version locking, and all >> use version control of that file as the unique mechanism for controlling >> whether to locked versions are shared across teams. >> >> We have many years of evidence that this model works well. >> >> Note that all of these package managers also work in in environments that do >> not support using multiple versions of a dependency in the same artifact at >> the same time. Therefore this statement from the proposal: >> >>> Overconstraint is much more of a risk in Swift than in other languages >>> using this style of package management. >> >> >> …is incorrect. >> >> In particular, note that Ruby does not support using multiple versions of a >> lib simultaneously, and that fact alone — even in the presence of >> _ubiquitous_ version pinning — has been sufficient to encourage widespread >> mindfulness about semver compliance. All of the concerns expressed in the >> “Pin by default” section of the proposal also apply to Ruby, and have failed >> to materialize there. >> >> — >> >> I’ve also used npm and bower, which either do not have version locking or >> only provide it via add-ons. It’s a nightmare. Lack of locking has caused >> headaches and lost hours — not hypothetic headaches, but real ones on actual >> projects — in two scenarios: >> >> 1. onboarding new developers who get fresh, incompatible dependency versions >> on initial checkout; and >> 2. picking projects back up for a new round of development. >> >> Are these two situations really the right time for people to accidentally >> test whether their dependencies have properly followed semantic versioning? >> No. There are better ways, and better times. I am troubled by the insistence >> on ignoring experience here. However, as I said above, I’m willing to give >> it a try. I will keep an open mind in the name of bold experimentation, and >> would be happy to have my concerns proven wrong. >> >> Please do keep in mind, however, that this is an experiment. Be ready for >> all that careful theorizing to be falsified by experience. You may have to >> murder this darling: >> http://www.slate.com/blogs/browbeat/2013/10/18/_kill_your_darlings_writing_advice_what_writer_really_said_to_murder_your.html >> >> <http://www.slate.com/blogs/browbeat/2013/10/18/_kill_your_darlings_writing_advice_what_writer_really_said_to_murder_your.html> >> >> >> How much effort did you put into your review? A glance, a quick reading, or >> an in-depth study? >> >> In depth, though I only read some of the discussion thread. >> >> Cheers, >> >> Paul >> >> >>> On Oct 31, 2016, at 4:23 PM, Anders Bertelrud via swift-evolution >>> <[email protected] <mailto:[email protected]>> wrote: >>> >>> Hello Swift community, >>> >>> The review of SE-0145 "Package Manager Version Pinning" begins now and runs >>> through November 4. The proposal is available here: >>> >>> >>> https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md >>> >>> <https://github.com/apple/swift-evolution/blob/master/proposals/0145-package-manager-version-pinning.md> >>> >>> Reviews are an important part of the Swift evolution process. All reviews >>> should be sent to the swift-evolution mailing list at >>> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >>> >>> or, if you would like to keep your feedback private, directly to the review >>> manager. >>> >>> What goes into a review? >>> >>> The goal of the review process is to improve the proposal under review >>> through constructive criticism and contribute to the direction of Swift. >>> When writing your review, here are some questions you might want to answer >>> in your review: >>> >>> * What is your evaluation of the proposal? >>> * Is the problem being addressed significant enough to warrant a change >>> to Swift? >>> * Does this proposal fit well with the feel and direction of Swift? >>> * If you have used other languages or libraries with a similar feature, >>> how do you feel that this proposal compares to those? >>> * How much effort did you put into your review? A glance, a quick >>> reading, or an in-depth study? >>> >>> More information about the Swift evolution process is available at >>> >>> https://github.com/apple/swift-evolution/blob/master/process.md >>> <https://github.com/apple/swift-evolution/blob/master/process.md> >>> >>> Thank you, >>> >>> Anders Bertelrud >>> Review Manager >>> _______________________________________________ >>> swift-evolution mailing list >>> [email protected] <mailto:[email protected]> >>> https://lists.swift.org/mailman/listinfo/swift-evolution >>> <https://lists.swift.org/mailman/listinfo/swift-evolution> >> >> _______________________________________________ >> swift-evolution mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-evolution >
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
