Confusing behavior of `destination` (`GenerateArgs`)

[Andrew15-5]

I was going through some code in Dioxus and found that for some reason destination isn't the destination at all if you don't use init. When you use init: false the project path is destination + name, while with init: true it's just destination. And it's get more confusing when comparing it to cargo's behavior. With cargo name is exclusively to override the crate's name, it doesn't participate in path creation at all. This makes new/init subcommands more in sync on how they behave, i.e., more natural/predictable to use/understand.

I want to hear why this project uses this convoluted strategy on path creation. I vote for sticking to cargo's behavior. One problem is that cargo uses path as an input and this project instead uses the name. This makes rewriting logic a bit harder. I'm in the process of rewriting dx new/init logic, so I should come up with a concrete solution when I'm done.

[sassman]

Maybe I don't understand your definition or expectation of destination. Maybe you can elaborate it?

I have tried combinations of using --destination, --init, and both. The results look consistent to me, but this might be because I am biased towards a specific meaning.

Here are the cases:

only --destination works a destination path

❯ cargo generate demo3 --destination x1
Using application config: /Users/d34dl0ck/.cargo/cargo-generate
🤷   Project Name: bar
🔧   Destination: /private/tmp/x1/bar ...
🔧   project-name: bar ...
🔧   Generating template ...
✔ 🤷   Which board do you use? · Arduino Uno
🔧   Moving generated files into: `/private/tmp/x1/bar`...
🔧   Initializing a fresh Git repository
✨   Done! New project created /private/tmp/x1/bar

only --init works as "use $CWD as the destination path without creating a project folder"

❯ mkdir x2
❯ cd x2

/tmp/x2
❯ cargo generate demo3 --init
Using application config: /Users/d34dl0ck/.cargo/cargo-generate
🤷   Project Name: bak
🔧   Destination: /private/tmp/x2 ...
🔧   project-name: bak ...
🔧   Generating template ...
✔ 🤷   Which board do you use? · Arduino Uno
🔧   Moving generated files into: `/private/tmp/x2`...
✨   Done! New project created /private/tmp/x2

both together is use destination as the folder but in there create no project with name baf

❯ mkdir x3
❯ cd x3

/tmp/x3
❯ cargo generate demo3 --init --destination xx
Using application config: /Users/d34dl0ck/.cargo/cargo-generate
🤷   Project Name: baf
🔧   Destination: /private/tmp/x3/xx ...
🔧   project-name: baf ...
🔧   Generating template ...
✔ 🤷   Which board do you use? · Arduino Uno
🔧   Moving generated files into: `/private/tmp/x3/xx`...
✨   Done! New project created /private/tmp/x3/xx

[Andrew15-5]

Maybe I don't understand your definition or expectation of destination. Maybe you can elaborate it?

It seems that your definition of destination is "overridden CWD". What I expect from destination is the "end destination of a project", i.e., the path where the project files are created.

So if you use destination plus project name (in the cargo-generate CLI), then the project path will be destination/name and not destination. I expect it to be destination. I hope this makes sense.

Try playing with cargo new <path> [--name] and cargo init [path] [--name]. You can also look at tests in https://github.com/DioxusLabs/dioxus/pull/2822. I already changed dx's syntax to follow cargo's one. For that, I had to use init: true for new and init subcommands (and explicit destination). Which obviously breaks the mental model of how/when init: true is used. That's where the confusion is. If I didn't have to use init: true in dx new then I probably wouldn't have opened this issue.