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.

Because:

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.

Thoughts?

> On Mar 29, 2016, at 11:33 AM, Ankit Agarwal via swift-build-dev 
> <[email protected]> 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
> Introduction
> 
> I propose to enable SwiftPM to use a package that is still under development 
> as a dependency for another package during testing and development.
> 
> Motivation
> 
> 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.
> 
> Acknowledgements
> 
> 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>
> 
> 
> -- 
> Ankit
> 
> 
> 
> _______________________________________________
> swift-build-dev mailing list
> [email protected]
> https://lists.swift.org/mailman/listinfo/swift-build-dev

_______________________________________________
swift-evolution mailing list
[email protected]
https://lists.swift.org/mailman/listinfo/swift-evolution

Reply via email to