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
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
