[swift-evolution] [Proposal] Lock file for Swift Package Manager

[Ankit Agarwal]

Lock File for Swift Package ManagerIntroduction

A Package.lock file containing list of resolved dependencies generated by
swiftpm.
Motivation

Package.lock file can be helpful in situations like :
Reproduce exact versions of dependencies on different machine
* Multiple developers working on a package would want to use the exact
versions (including minor and patch) of the dependencies declared in the
manifest file
* Also helpful when a build is being performed on a remote machine eg CI
Pointing a dependency to an untagged commit
Sometimes it might be helpful to lock a dependency to a particular commit
ref for which a tagged version is unavailable in cases such as :

* Forking a 3rd party library and making it swiftpm compatible for
temporary use until officially supported by the author
* Package is in active development and not ready for a release tag
Proposed Solution

swiftpm generates a simple Package.lock file after resolving the dependency
graph for that package in some simple format.
Detailed Design
1. Initial$ swift build resolves the dependency graph and generates a
Package.lock file similar to :

ssh://github.com/foo/bar "v1.2.3"http://github.com/foo/baz "v1.0.0"
../local/git/repo "v3.4.4"

lock file will only be re-modified by $ swift build if Package.swift is
modified by the user.
$ swift build always ignores the lock file and uses local state of Packages
dir / Package.swift

2. User modifies the cloned packages in Packages dir and when satisfied
with the current code of the dependency, commits and pushes it.
To lock the current state of Packages user can run  $ swift build --lock which
might result something similar to

ssh://github.com/foo/bar
"248441ff375a19c4365d00d6b0706e11173074f6"http://github.com/foo/baz
"v1.0.0"
../local/git/repo "v3.4.4"

the lock file is committed into the package repo for others to use.

3. A command like $ swift build --bootstrap will always use the lock file
to fetch and checkout the dependencies.
This is useful because running  $ swift build might give a higher patch or
minor version of the dependency.

4. If some dependency depends on commit hash (ie non-tagged commit) the
author mentions that in their readme and the end user and maybe other
parallel dependencies will have to use only that commit hash in order to
avoid dependency hell.

5. Allow declaring a dependency without versions in the manifest file for
user wanting to use a untagged dependency. This should probably only be
allowed in debug configuration.
Impact on existing code
None as this would be additional functionality to swift package manager
Alternatives Considered
One alternative is to allow mentioning refs in manifest file while
declaring a dependency but as discussed in this
<https://lists.swift.org/pipermail/swift-build-dev/Week-of-Mon-20151214/000067.html>
thread it might not be the best idea.

-- 
Ankit
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.swift.org/pipermail/swift-evolution/attachments/20151220/cf6273e5/attachment.html>