`swift package init` creates a package in the current directory, rather than taking explicit input or using given package name as directory

[eliperkins]

Description

This can often clutter up or conflict with content in the current directory and create a confusing experience for folks who aren't familiar with the undocumented behavior of where swift package init will place content.

This also gets confusing with the --name parameter, which might lead folks to believe that the package will be placed in a directory named that name.

Expected behavior

swift package init takes in an argument for the directory to place the package into.

Actual behavior

swift package init always creates a package in the current working directory.

Steps to reproduce

1. Run swift package init with no arguments
2. Verify the package is created in the current working directory
3. Run swift package init --name SomePkg
4. Verify that the content isn't placed in a SomePkg directory
5. Run swift package init --name SomePkg MyPkg
6. Verify that the command errors with error: Unexpected argument 'MyPkg'

Swift Package Manager version/commit hash

691f9310bc6cb599687e7e5ecad15afc50656294

Swift & OS version (output of swift --version && uname -a)

swift-driver version: 1.111.2 Apple Swift version 6.0 (swiftlang-6.0.0.5.15 clang-1600.0.22.6) Target: arm64-apple-macosx14.0 Darwin Elis-MBP-3 23.6.0 Darwin Kernel Version 23.6.0: Wed Jul 10 01:20:40 PDT 2024; root:xnu-10063.141.1~4/RELEASE_ARM64_T6000 arm64

[eliperkins]

I took a stab at this here: https://github.com/swiftlang/swift-package-manager/pull/7792

[MaxDesiatov]

As any change in SwiftPMs public API and CLI commands, this seems significant enough to require a pitch and a subsequent Swift Evolution proposal if it's successful at the pitch phase.

[eliperkins]

Sounds good. I can put together a pitch for this then 👍

For my understanding, which part of this change do you deem significant/substantial? I'd love to use to that to refine the pitch.

[MaxDesiatov]

cc @bnbarham

[grynspan]

You can pass an explicit path using --package-path, FWIW.

[bnbarham]

this seems significant enough to require a pitch and a subsequent Swift Evolution proposal if it's successful at the pitch phase

I'd say it's worth talking about on the forums at minimum - there's a few ways this could be implemented. Some examples:

1. Use --package-path. Would need a fix to create the directory by default (at least for init). One major downside is that it's a package argument and thus has to come before init. It is also not part of the help for init (for the same reason).
2. Use --name as the directory if given. This would be a breaking change though.
3. (your PR) Go the route of git init and take an optional path argument. Interaction between this and --package-path is a little weird, but still well-defined.

[dschaefer2]

this seems significant enough to require a pitch and a subsequent Swift Evolution proposal if it's successful at the pitch phase

I'd say it's worth talking about on the forums at minimum - there's a few ways this could be implemented. Some examples:

1. Use --package-path. Would need a fix to create the directory by default (at least for init). One major downside is that it's a package argument and thus has to come before init. It is also not part of the help for init (for the same reason).

I like this. It's consistent use of --package-path that comes up with swift build too.

2. Use --name as the directory if given. This would be a breaking change though.
3. (your PR) Go the route of git init and take an optional path argument. Interaction between this and --package-path is a little weird, but still well-defined.

And I don't mind this. git init is how I started to think when using swift package init. And it is likely the next command you run once you init the package. :).

[grynspan]

I personally prefer consistency with the other subcommands, i.e. --package-path, but I am but one voice in a sea of… several!