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

[Paul Cantrell]

+1 for Ankit’s general idea. Details of the proposal aside, I’ll say from experience with bundler that it’s immensely useful — a lifesaver! — to know the exact version of the dependencies another author was using. This has saved my neck more than once.

IMO it’s useful to have a lock file checked in even for libraries — just not pushed forward to client projects. You still want to know what versions the library’s tests last passed against, both for CI and for diagnosing downstream breakage.

-1 to this:

> [The] 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
> …
> To lock the current state of Packages user can run  $ swift build --lock


A couple of problems with that:

(1) Package.swift can specify a version range. You may want to update to the latest patch release without actually modifying Package.swift. I agree with Thomas: there should be a command to update dependencies to the latest matching version. This command should also be able update a single dependency:

	swift build --update SomePackage

(2) I don’t like the idea of the build system running in two separate modes, where sometimes the lock file is ignored and sometimes takes precedence. (If there’s a desire to run in an “unlocked” mode, how about it just doesn't generate the .lock if not already present, and always uses it if it is present?) In practice, though, I’ve found the bundler model works quite well: always generate .lock if absent, always use the locked version if present, and use a separate command to update the locked version.

Cheers,

Paul

> On Dec 20, 2015, at 9:51 AM, Thomas Guthrie via swift-evolution <swift-evolution at swift.org> wrote:
> 
> 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 <mailto: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 <mailto:swift-evolution at swift.org>
>> https://lists.swift.org/mailman/listinfo/swift-evolution
> 
> 
> _______________________________________________
> 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/20b8f83a/attachment.html>