Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
eliperkins opened this issue Jul 17, 2024 · 8 comments · May be fixed by #7792

Comments

@eliperkins
Copy link

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

691f931

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
Copy link
Author

I took a stab at this here: #7792

@MaxDesiatov
Copy link
Contributor

MaxDesiatov commented Jul 18, 2024

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
Copy link
Author

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
Copy link
Contributor

cc @bnbarham

@grynspan
Copy link
Contributor

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

@bnbarham
Copy link
Contributor

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
Copy link
Member

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.

  1. Use --name as the directory if given. This would be a breaking change though.
  2. (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
Copy link
Contributor

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants