Open eliperkins opened 1 month ago
I took a stab at this here: https://github.com/swiftlang/swift-package-manager/pull/7792
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.
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.
cc @bnbarham
You can pass an explicit path using --package-path
, FWIW.
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:
--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).--name
as the directory if given. This would be a breaking change though.git init
and take an optional path argument. Interaction between this and --package-path
is a little weird, but still well-defined.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:
- Use
--package-path
. Would need a fix to create the directory by default (at least forinit
). One major downside is that it's apackage
argument and thus has to come beforeinit
. It is also not part of the help forinit
(for the same reason).
I like this. It's consistent use of --package-path
that comes up with swift build
too.
- Use
--name
as the directory if given. This would be a breaking change though.- (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. :).
I personally prefer consistency with the other subcommands, i.e. --package-path
, but I am but one voice in a sea of… several!
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
swift package init
with no argumentsswift package init --name SomePkg
SomePkg
directoryswift package init --name SomePkg MyPkg
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