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

[Thomas Guthrie]

Personally, I’d be more in favour of having something similar to Cargo (Rust’s package/crate manager):

1. `swift build`

Almost the same as it is now, expect if there’s no Package.lock it creates one and subsequent builds use the same dependencies.

2. `swift build --update` or maybe eventually `swift update`

Updates the dependencies in Package.lock to their newest versions and writes them to disk. It should probably build the project as well but possibly makes less sense if its `swift update`.

Similar to Bundler and Cargo you’d check in your Package.lock for app projects and ignore it for library projects.

I’m not really sure what their motivation was for having a lock file always created, it definitely favours “app” projects heavily, but I’ve been messing around with Rust recently and it works pretty well honestly. Maybe there’s a way of making the experience better when the package is solely a library? Personally, if you’re developing a library and `swift build` updates a dependency that breaks everything it’s probably better to know then, whereas with an app you probably want to be working to a lock file and checking what happens when you update dependencies individually.

As for the format of Package.lock, I think it might have to be more complicated than shown to be able to handle the possibility of multiple versions of a dependency etc? Haven’t had a chance to mess around with swiftpm enough yet to say though.

(/end ramble of first thoughts)

— Thomas

> On 20 Dec 2015, at 09:01, Ankit Agarwal via swift-evolution <swift-evolution at swift.org> wrote:
> 
> Lock File for Swift Package Manager
> Introduction
> 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 <http://github.com/foo/bar> "v1.2.3"
> http://github.com/foo/baz <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 <http://github.com/foo/bar> "248441ff375a19c4365d00d6b0706e11173074f6"
> http://github.com/foo/baz <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
>  _______________________________________________
> swift-evolution mailing list
> swift-evolution at swift.org
> https://lists.swift.org/mailman/listinfo/swift-evolution

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