I also strongly agree with this, I'd prefer version pinning to happen by default, rather than with explicit command as it will make builds reproducible by default.
I totally agree that we can rely on past experience with other package managers (npm being the case), where pinning with a separate command caused more harm than good. Overall, I think that it would be great if Package.lock was created by default when it's not present and be updated only with an explicit command for updating. With best regards, Max. > On 14 Oct 2016, at 08:29, orta therox via swift-build-dev > <[email protected]> wrote: > > Please don’t make this a separate command, it should ideally be created at > the end of an build (when there isn’t one already) or an update of your > dependencies - most people will be expecting to get the same set of > dependencies as the rest of their team. This pattern makes that harder. > > NPM shrinkwrap is an example of this, and it’s a bad one - I’ve wasted a lot > of time trying to keep that up to date for our npm projects. Facebook made a > replacement for NPM with mainly the feature of “always locking” in yarn > <https://yarnpkg.com/> and I’d expect that to take a lot of the JS mindshare > on this one feature alone. > > -- > > [A.] Orta Therox > >> w/ Artsy <http://artsy.net/>CocoaPods <http://cocoapods.org/> / CocoaDocs >> <http://cocoadocs.org/> / GIFs.app >> <https://itunes.apple.com/us/app/gifs/id961850017?l=en&mt=12> >> @orta <http://twitter.com/orta> / orta.github.com <http://orta.github.com/> >> Artsy is totally hiring iOS Devs <https://artsy.net/job/mobile-engineer> ATM > >> On 14 Oct 2016, at 07:01, Ankit Aggarwal via swift-build-dev >> <[email protected] <mailto:[email protected]>> wrote: >> >> Hi, >> >> We're proposing version pinning feature in Swift Package Manager. The >> proposal is available here >> <https://github.com/aciidb0mb3r/swift-evolution/blob/version-pinning/proposals/NNNN-Version-Pinning.md> >> and also in this email: >> >> Feedback welcomed! >> >> Thanks, >> Ankit >> >> -------- >> >> Package Manager Version Pinning >> Proposal: SE-XXXX >> Author: Daniel Dunbar <https://github.com/ddunbar>, Ankit Aggarwal >> <https://github.com/aciidb0mb3r> >> Review Manager: TBD >> Status: Discussion >> Introduction >> This is a proposal for adding package manager features to "pin" or "lock" >> package dependencies to particular versions. >> >> Motivation >> As used in this proposal, version pinning refers to the practice of >> controlling exactly which specific version of a dependency is selected by >> the dependency resolution algorithm, independent from the semantic >> versioning specification. Thus, it is a way of instructing the package >> manager to select a particular version from among all of the versions of a >> package which could be chosen while honoring the dependency constraints. >> >> Terminology >> >> We have chosen to use "pinning" to refer to this feature, over "lockfiles", >> since the term "lock" is already overloaded between POSIX file locks and >> locks in concurrent programming. >> >> Philosophy >> >> Our philosophy with regard to pinning is that we actively want to encourage >> packages to develop against the latest semantically appropriate versions of >> their dependencies, in order to foster rapid development amongst the >> ecosystem and strong reliance on the semantic versioning concept. Our design >> for version pinning is thus intended to be a feature for package authors and >> users to use in crafting specific workflows, not be a mechanism by which >> most of the packages in the ecosystem pin themselves to specific versions of >> each other. >> >> Use Cases >> >> Our proposal is designed to satisfy several different use cases for such a >> behavior: >> >> Standardizing team workflows >> >> When collaborating on a package, it can be valuable for team members (and >> continuous integration) to all know they are using the same exact version of >> dependencies, to avoid "works for me" situations. >> >> This can be particularly important for certain kinds of open source projects >> which are actively being cloned by new users, and which want to have some >> measure of control around exactly which available version of a dependency is >> selected. >> >> Difficult to test packages or dependencies >> >> Complex packages which have dependencies which may be hard to test, or hard >> to analyze when they break, may choose to maintain careful control over what >> versions of their upstream dependencies they recommend -- even if >> conceptually they regularly update those recommendations following the true >> semantic version specification of the dependency. >> >> Dependency locking w.r.t. deployment >> >> When stabilizing a release for deployment, or building a version of a >> package for deployment, it is important to be able to lock down the exact >> versions of dependencies in use, so that the resulting product can be >> exactly recreated later if necessary. >> >> Proposed solution >> We will introduce support for an optional new file Package.pins adjacent to >> the Package.swift manifest, called the "pins file". We will also introduce a >> number of new commands (see below) for maintaining the pins file. >> >> This file will record the active version pin information for the package, >> including data such as the package identifier, the pinned version, and >> explicit information on the pinned version (e.g., the commit hash/SHA for >> the resolved tag). >> >> The exact file format is unspecified/implementation defined, however, in >> practice it will be a JSON data file. >> >> This file may be checked into SCM by the user, so that its effects apply to >> all users of the package. However, it may also be maintained only locally >> (e.g., placed in the .gitignore file). We intend to leave it to package >> authors to decide which use case is best for their project. >> >> In the presence of a Package.pins file, the package manager will respect the >> pinned dependencies recorded in the file whenever it needs to do dependency >> resolution (e.g., on the initial checkout or when updating). >> >> The pins file will not override Manifest specified version requirements and >> it will be an error (with proper diagnostics) if there is a conflict between >> the pins and the manifest specification. >> >> Detailed Design >> We will add a new command pin to swift package tool with following semantics: >> >> $ swift package pin ( [--all] | [<package-name>] [<version>] ) [--message >> <message>] >> The package-name refers to the name of the package as specified in its >> manifest. >> >> This command pins one or all dependencies. The command which pins a single >> version can optionally take a specific version to pin to, if unspecified (or >> with --all) the behaviour is to pin to the current package version in use. >> Examples: >> >> $ swift package pin --all - pins all the dependencies. >> $ swift package pin Foo - pins Foo at current resolved version. >> $ swift package pin Foo 1.2.3 - pins Foo at 1.2.3. The specified version >> should be valid and resolvable. >> The --reason option is an optional argument to document the reason for >> pinning a dependency. This could be helpful for user to later remember why a >> dependency was pinned. Example: >> >> $ swift package pin Foo --reason "The patch updates for Foo are really >> unstable and need screening." >> Dependencies are never automatically pinned, pinning is only ever taken as a >> result of an explicit user action. >> >> We will add a new command unpin: >> >> $ swift package unpin ( [--all] | [<package-name>] ) >> This is the counterpart to the pin command, and unpins one or all packages. >> >> We will fetch and resolve the dependencies when running the pin commands, in >> case we don't have the complete dependency graph yet. >> >> We will extend the workflow for update to honour version pinning, that is, >> it will only update packages which are unpinned, and it will only update to >> versions which can satisfy the existing pins. The update command will, >> however, also take an optional argument --repin: >> >> $ swift package update [--repin] >> Update command errors if there are no unpinned packages which can be updated. >> >> Otherwise, the behaviour is to update all unpinned packages to the latest >> possible versions which can be resolved while respecting the existing pins. >> >> The [--repin] argument can be used to lift the version pinning restrictions. >> In this case, the behaviour is that all packages are updated, and packages >> which were previously pinned are then repinned to the latest resolved >> versions. >> >> The update and checkout will both emit logs, notifying the user that pinning >> is in effect. >> >> The swift package show-dependencies subcommand will be updated to indicate >> if a dependency is pinned. >> >> As a future extension, we anticipate using the SHA information recorded in a >> pins file as a security feature, to prevent man-in-the-middle attacks on >> parts of the package graph. >> >> Impact on existing code >> There will be change in the behaviours of swift build and swift package >> update in presence of the pins file, as noted in the proposal however the >> existing package will continue to build without any modifications. >> >> Alternative considered >> We considered making the pinning behavior default on running swift build, >> however we think that pinning by default is likely to make the package graph >> more constrained than it should be. It drives the user away from taking full >> advantage of semantic versioning. We think it will be good for the package >> ecosystem if such a restriction is not the default behavior and that this >> design will lead to faster discovery of bugs and fixes in the upstream. >> >> >> >> _______________________________________________ >> swift-build-dev mailing list >> [email protected] <mailto:[email protected]> >> https://lists.swift.org/mailman/listinfo/swift-build-dev > > _______________________________________________ > swift-build-dev mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-build-dev
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
