[swift-evolution] [swift-build-dev] [Draft] SwiftPM: Adding development package as a dependency
max.howell at apple.com
Tue Mar 29 13:44:31 CDT 2016
This was more or less what I’ve been thinking, but lately I’ve been also thinking it would be great if:
You didn’t have to modify Package.swift to get this feature.
1) You have to remember to modify it back at some point, and if you are iterating frequently this is tedious and error-prone
2) We don’t want any chance that DevPackage gets into the package graph and thus the ecosystem.
> On Mar 29, 2016, at 11:33 AM, Ankit Agarwal via swift-build-dev <swift-build-dev at swift.org> wrote:
> SwiftPM: Adding development package as a dependency
> Proposal: SE-NNNN <https://github.com/apple/swift-evolution/blob/master/proposals/NNNN-name.md>
> Author(s): Ankit Aggarwal <https://github.com/aciidb0mb3r>
> Status: Awaiting review
> Review manager: TBD
> I propose to enable SwiftPM to use a package that is still under development as a dependency for another package during testing and development.
> During development of libraries, developers commonly want to try out their module package as a dependency. This emulates the typical library use-case and is currently not possible in SwiftPM without first checking in and tagging that library. These extra steps, while reasonable for an already-built package, are an unnecessary burden for a package that remains in development.
> Forcing the user to modify the library package inside Packages to continue development or continuously reclone the package after recommiting and retagging strain the process of building the library in the first place.
> Detail Design
> Under this proposal, the root package will be allowed to specify a DevPackage dependency. This dependency will not clone the package inside Packages/ or require the dependency to be under version control. This will free the developer to continue iterative testing, expansion, and enhancements without being tied to the current dependency system.
> This approach limits DevPackage dependencies to local file systems. Remote repositories cannot be used with this keyword.
> The following example demonstrates what a manifest file would look like. In this example, the DevPackage is specified using a local path and the majorVersion is used as is for this DevPackage.
> import PackageDescription
> let package = Package(
> name: "MyLibraryTester",
> dependencies: [
> .Package(url: "https://github.com/apple/example-package-fisheryates.git <https://github.com/apple/example-package-fisheryates.git>", majorVersion: 1),
> .DevPackage(localPath: "../MyAwesomeLibrary", majorVersion: 1),
> Under this design:
> DevPackage is limited strictly to the root package. The manifest of any dependency containing a DevPackage will fail to build.
> A DevPackage is not copied inside Packages/ and does not require version control.
> SwiftPM uses the DevPackage's source directory for building, permitting in-place development on the local file system.
> SwiftPM disallows non-local DevPackage sources. To use a remote package, the developer must first clone a package and then specify the local path.
> Version numbers are specified for DevPackage entries within the manifest file.
> Should the DevPackage version not be selected after resolving the dependency graph, the build will succeed with a warning.
> Impact on existing code
> This proposal does not impact existing code.
> Alternatives considered
> I propose two possible alternatives to this problem:
> Create a executable target within the library package for development testing.
> Use XCTest to test the library.
> Both alternate approaches permit testing a library module but they will not simulate a full SwiftPM package.
> Thanks to Erica Sadun <https://github.com/erica> for inputs.
> Github link: https://github.com/aciidb0mb3r/swift-evolution/blob/swiftpm_dev_package/proposals/NNNN-swiftpm-development-package-as-dependency.md <https://github.com/aciidb0mb3r/swift-evolution/blob/swiftpm_dev_package/proposals/NNNN-swiftpm-development-package-as-dependency.md>
> swift-build-dev mailing list
> swift-build-dev at swift.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the swift-evolution