It's be nice to include a bit about how these interact with generated Xcodeproj files. In Cocoapods those end up in a separate grouping, which I find to be beneficial.
Sent from my iPhone > On Mar 29, 2016, at 11:33 AM, Ankit Agarwal via swift-evolution > <[email protected]> wrote: > > SwiftPM: Adding development package as a dependency > Proposal: SE-NNNN > Author(s): Ankit Aggarwal > 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";, 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 for inputs. > > > ------------------------------------------------------------------------ > > Github link: > https://github.com/aciidb0mb3r/swift-evolution/blob/swiftpm_dev_package/proposals/NNNN-swiftpm-development-package-as-dependency.md > > > -- > Ankit > > > > _______________________________________________ > swift-evolution mailing list > [email protected] > https://lists.swift.org/mailman/listinfo/swift-evolution
_______________________________________________ swift-evolution mailing list [email protected] https://lists.swift.org/mailman/listinfo/swift-evolution
