# SE-0301: Package Editor Commands **URL:** \ **Category:** Proposal Reviews\ **Tags:** packagemanager\ **Created:** [February 4, 2021, 5:25pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447 "2021-02-04T17:25:55Z")\ **Posts on this page:** 20\ **Page:** 1
**Author:** ![tomerd](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/tomerd/32/3402_2.png) [@tomerd](https://forums.swift.org/u/tomerd)\ **Post date:** [February 4, 2021, 5:25pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/1 "2021-02-04T17:25:55Z")
The review of [SE-0301](https://github.com/apple/swift-evolution/blob/main/proposals/0301-package-editing-commands.md), begins now and runs through February 15, 2021. Reviews are an important part of the Swift evolution process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager or direct message in the Swift forums). ## What goes into a review of a proposal? The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, determine the direction of Swift. When reviewing a proposal, here are some questions to consider: - What is your evaluation of the proposal? - Is the problem being addressed significant enough to warrant a change to Swift? - Does this proposal fit well with the feel and direction of Swift? - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Thank you for helping improve the Swift programing language and ecosystem. Tom Doron Review Manager ---
**Author:** ![johannesweiss](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/johannesweiss/32/38183_2.png) [@johannesweiss](https://forums.swift.org/u/johannesweiss)\ **Post date:** [February 4, 2021, 8:53pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/2 "2021-02-04T20:53:04Z")
Oh wow, this is awesome. In SwiftNIO, we're [generating](https://github.com/apple/swift-nio/blob/bc328cd3a87298f46b5b53d65d656191498eba48/IntegrationTests/allocation-counter-tests-framework/run-allocation-counter.sh) ad-hoc [packages](https://github.com/apple/swift-nio/blob/bc328cd3a87298f46b5b53d65d656191498eba48/dev/make-single-file-spm) in [`bash`](https://github.com/apple/swift-nio/blob/bc328cd3a87298f46b5b53d65d656191498eba48/dev/make-single-file-spm) a [bunch](https://github.com/apple/swift-nio/blob/bc328cd3a87298f46b5b53d65d656191498eba48/IntegrationTests/tests_05_assertions/defines.sh) in [our](https://github.com/apple/swift-nio/blob/bc328cd3a87298f46b5b53d65d656191498eba48/IntegrationTests/tests_02_syscall_wrappers/defines.sh) integration test suites a bunch and it's _very painful_. This will make this so much better, so definitely +1 🙂 . ---
**Author:** ![lukasa](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/lukasa/32/1232_2.png) [@lukasa](https://forums.swift.org/u/lukasa)\ **Post date:** [February 5, 2021, 2:34pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/3 "2021-02-05T14:34:31Z")
I think this is a great enhancement. It fits well with SwiftPM, addresses a substantial pain point, and does so in a way that will be generally understandable and useable. +1. ---
**Author:** ![SwiftUI](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/swiftui/32/24361_2.png) [@SwiftUI](https://forums.swift.org/u/SwiftUI)\ **Post date:** [February 5, 2021, 2:42pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/4 "2021-02-05T14:42:37Z")
Nice Better CLI and Xcode IDE support. +1 ---
**Author:** ![George](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/george/32/37757_2.png) [@George](https://forums.swift.org/u/George)\ **Post date:** [February 5, 2021, 4:11pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/5 "2021-02-05T16:11:11Z")
I like this, but have a couple suggestions: 1. If we are to draw a line between “declarative” and “non-declarative” Swift packages, we should make explicit what that entails and provide a mechanism to verify that a package is declarative. Maybe something like `swift package manifest-is-declarative`. This would enable projects to validate in CI that the proposed command line operations will work. 2. We should consider having getters for all these items. It would be nice to have symmetry, and we can later add more complex operations like extracting the pinned revision of a particular dependency. ---
**Author:** ![owenv](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/owenv/32/6137_2.png) [@owenv](https://forums.swift.org/u/owenv)\ **Post date:** [February 5, 2021, 4:34pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/6 "2021-02-05T16:34:19Z")
> [@George](#): > > If we are to draw a line between “declarative” and “non-declarative” Swift packages, we should make explicit what that entails and provide a mechanism to verify that a package is declarative. Maybe something like `swift package manifest-is-declarative` . This would enable projects to validate in CI that the proposed command line operations will work. This is feasible and in general I think some kind of package linter would be a good future extension, but I'm somewhat concerned it could be confusing to users in the short term depending on how it's presented. For example, one user may only care about adding new dependencies via the CLI, and it's possible their dependencies list is declarative, but some other part of the manifest isn't. Is a global linting operation still going to be useful to them? I don't have a good answer to this yet. > [@George](#): > > We should consider having getters for all these items. It would be nice to have symmetry, and we can later add more complex operations like extracting the pinned revision of a particular dependency. `swift package dump-package` includes all or most of this information. If there's anything missing, I think it's best to add it there instead of introducing new subcommands. ---
**Author:** ![Michael\_Ilseman](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/michael_ilseman/32/44640_2.png) [@Michael\_Ilseman](https://forums.swift.org/u/Michael_Ilseman)\ **Post date:** [February 5, 2021, 4:46pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/7 "2021-02-05T16:46:58Z")
Enthusiastic +1 from me. These tools would help me avoid fiddly details and save time when refactoring packages. ---
**Author:** ![finestructure](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/finestructure/32/34879_2.png) [@finestructure](https://forums.swift.org/u/finestructure)\ **Post date:** [February 5, 2021, 8:49pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/8 "2021-02-05T20:49:23Z")
This is great! It should be very helpful for a tool of mine that creates playgrounds with dependencies and it would enable a feature we’ve considered for the Swift Package Index where we’d provide a copy-pasteable command to add a dependency from a package page. +1 ---
**Author:** ![eneko](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/eneko/32/12117_2.png) [@eneko](https://forums.swift.org/u/eneko)\ **Post date:** [February 7, 2021, 6:10am UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/9 "2021-02-07T06:10:10Z")
- What is your evaluation of the proposal? Great! +1 - Is the problem being addressed significant enough to warrant a change to Swift? Yes - Does this proposal fit well with the feel and direction of Swift? Yes - If you have used other languages or libraries with a similar feature, how do you feel that this proposal compares to those? Proposal includes examples from other package managers. - How much effort did you put into your review? A glance, a quick reading, or an in-depth study? Read the proposal end-to-end and this thread. ---
**Author:** ![Doug](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/doug/32/7679_2.png) [@Doug](https://forums.swift.org/u/Doug)\ **Post date:** [February 8, 2021, 2:08pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/10 "2021-02-08T14:08:52Z")
Happy to see this has made it to the review stage, very much a +1 from me. One area I’m left slightly unsure about is around updating binary targets as they don’t seem to fit into the automatic `upgrade` command mentioned in Future Directions. Presumably these would essentially require running the `add-target` command again to pass in the latest URL and checksum. It’s probably out of scope for this initial proposal, but thought I’d mention it for the future. ---
**Author:** ![owenv](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/owenv/32/6137_2.png) [@owenv](https://forums.swift.org/u/owenv)\ **Post date:** [February 10, 2021, 4:44am UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/11 "2021-02-10T04:44:52Z")
> [@Doug](#): > > One area I’m left slightly unsure about is around updating binary targets as they don’t seem to fit into the automatic `upgrade` command mentioned in Future Directions. Yeah, what I had in mind for an `upgrade` command was that it wouldn't touch anything other than dependencies. Updating targets would probably require a different command and/or API, but I think it's an interesting potential future direction. I could see it being useful for certain continuous integration workflows. ---
**Author:** ![Doug](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/doug/32/7679_2.png) [@Doug](https://forums.swift.org/u/Doug)\ **Post date:** [February 10, 2021, 12:36pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/12 "2021-02-10T12:36:44Z")
> [@owenv](#): > > I could see it being useful for certain continuous integration workflows. Bingo! It would make one my current workflows feel less fragile. ---
**Author:** ![wowbagger](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/wowbagger/32/13847_2.png) [@wowbagger](https://forums.swift.org/u/wowbagger)\ **Post date:** [February 10, 2021, 10:50pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/13 "2021-02-10T22:50:43Z")
> **dependencies** : A comma separated list of target dependency names. > ```swift > swift package add-target MyExecutable --type executable --dependencies MyLibrary,ArgumentParser > > ``` For options that can take more than 1 value, would it be better to use the [`.upToNextOption`](https://github.com/apple/swift-argument-parser/blob/75c4dcd2e7cd0878aa1d29e6b493a8abcd65d753/Sources/ArgumentParser/Parsable%20Properties/Option.swift#L247) parsing strategy? Then the user would be able to separate values by space, like in most existing commands: ```swift swift package add-target MyExecutable --type executable --dependencies MyLibrary ArgumentParser ``` ---
**Author:** ![owenv](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/owenv/32/6137_2.png) [@owenv](https://forums.swift.org/u/owenv)\ **Post date:** [February 11, 2021, 3:42am UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/14 "2021-02-11T03:42:30Z")
> [@wowbagger](#): > > For options that can take more than 1 value, would it be better to use the [`.upToNextOption`](https://github.com/apple/swift-argument-parser/blob/75c4dcd2e7cd0878aa1d29e6b493a8abcd65d753/Sources/ArgumentParser/Parsable%20Properties/Option.swift#L247) parsing strategy? I took a look through the existing SwiftPM commands and couldn't find any similar options, so I guess SwiftPM doesn't have any existing precedent to follow (the compiler uses spaces for input files though, which is kinda similar). I'm open to changing it if folks think spaces would be a better delimiter. ---
**Author:** ![wowbagger](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/wowbagger/32/13847_2.png) [@wowbagger](https://forums.swift.org/u/wowbagger)\ **Post date:** [February 11, 2021, 5:29am UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/15 "2021-02-11T05:29:40Z")
> [@wowbagger](#): > > like in most existing commands > [@owenv](#): > > SwiftPM doesn't have any existing precedent to follow Sorry, my previous comment was ambiguous. By "existing commands", I mean those from other command line tools/programs. For example: ```swift rm file1 file2 git add file1 path/to/file2 npm install package1 package2 ``` * * * Adding to my previous comment, another thing I just realised is that package names can have spaces in them. So it seems to me that it's more ergnomic to write a command like this: ```swift swift package add-product MyLibrary --targets "target foo" "target bar" ``` than like this: ```swift swift package add-product MyLibrary --targets "target foo,target bar" ``` Also, I think separating option values by space can help the user avoid typos where a space is typed after a comma out of habit. * * * **Update** 2021-02-12: Another point in favor for space-separated array of strings: Package names can have commas in them. It can be problematic to parse them in a comma-delimited string: ```swift # target names are "target,foo" and "target,,,bar" swift package add-product MyLibrary --targets target,foo,target,,,bar ``` Unlike space-separated array of strings, you can't get around this by using `"` or `\`. ---
**Author:** ![James\_Dempsey](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/james_dempsey/32/14336_2.png) [@James\_Dempsey](https://forums.swift.org/u/James_Dempsey)\ **Post date:** [February 13, 2021, 6:33pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/16 "2021-02-13T18:33:17Z")
I am +1 for the proposal, but do think the multiple-value options should be space-delimited. > [@owenv](#): > > I'm open to changing it if folks think spaces would be a better delimiter. I agree with @wowbagger that a space-delimited list of targets and dependencies would be better. It avoids the naming edge cases mentioned by @wowbagger. I think even more importantly, many other command line tools use space-separated values, so that will likely be more familiar to users than comma-separated values. One other approach not mentioned is how the swift command itself deals with multiple values. It allows for using the same option flag multiple times rather than taking multiple values with a single option flag, which is another approach. So, instead of `--targets Foo,Bar` it would be `--target Foo --target Bar`. Of these three approaches: - Comma-separated values `--targets "Foo,Bar,Fancy Target"` - Space-separated values `--targets Foo Bar "Fancy Target"` - Repeated single-value option flags `--target Foo --target Bar --target "Fancy Target"` For me, the space-separated values are the most readable, the most similar to other command line tool usage and much more compact than the repeated option flags approach. ---
**Author:** ![freda](https://avatars.discourse-cdn.com/v4/letter/f/47e85d/32.png) [@freda](https://forums.swift.org/u/freda)\ **Post date:** [February 14, 2021, 2:13pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/17 "2021-02-14T14:13:21Z")
The example uses these commands to update the `Package.swift` file: ```bash swift package add-dependency https://github.com/apple/swift-argument-parser swift package add-target MyLibraryTests --type test --dependencies MyLibrary swift package add-target MyExecutable --type executable --dependencies MyLibrary,ArgumentParser swift package add-product MyLibrary --targets MyLibrary ``` In this example the target `MyLibrary` is used before it is being defined. Does referring to an unknown dependency cause warnings in step 2 and 3 or is this silently ignored? My preference would be a warning since this could be the result of a simple typo. ---
**Author:** ![owenv](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/owenv/32/6137_2.png) [@owenv](https://forums.swift.org/u/owenv)\ **Post date:** [February 14, 2021, 6:10pm UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/18 "2021-02-14T18:10:12Z")
> [@freda](#): > > In this example the target `MyLibrary` is used before it is being defined. ```swift // swift-tools-version:5.3 import PackageDescription // Description of my package let package = Package( name: "MyPackage", targets: [ .target( name: "MyLibrary", // Utilities dependencies: [] ), ] ) ``` On lines 2 & 3, `MyLibrary` refers to the existing target with that name from the original manifest, so there's no problem. If I instead started with an empty manifest like this: ```swift // swift-tools-version:5.3 import PackageDescription // Description of my package let package = Package( name: "MyPackage" ) ``` Running the same commands would report errors for lines 2, 3, and 4, and the only edit applied would be the one adding swift-argument-parser to the dependencies list. That's because if, for example, we applied the edit requested in line 2, the manifest would no longer load. By only applying edits which result in a loadable manifest, we can guarantee that using the new commands on a manifest which is initially machine-editable will preserve that property. ---
**Author:** ![freda](https://avatars.discourse-cdn.com/v4/letter/f/47e85d/32.png) [@freda](https://forums.swift.org/u/freda)\ **Post date:** [February 15, 2021, 12:17am UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/19 "2021-02-15T00:17:07Z")
Thanks for the clarification ---
**Author:** ![nrith](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/nrith/32/7179_2.png) [@nrith](https://forums.swift.org/u/nrith)\ **Post date:** [February 15, 2021, 2:43am UTC](https://forums.swift.org/t/se-0301-package-editor-commands/44447/20 "2021-02-15T02:43:59Z")
Another vote for space-delimited values! This will be a great addition to SPM. It feels very Rails-like, which I suppose is ultimately one of the influences on the proposal. [Next page](https://forums.swift.org/t/se-0301-package-editor-commands/44447.md?page=2)