{"action":"created","issue":{"url":"https://api.github.com/repos/rust-lang/cargo/issues/6100","repository_url":"https://api.github.com/repos/rust-lang/cargo","labels_url":"https://api.github.com/repos/rust-lang/cargo/issues/6100/labels{/name}","comments_url":"https://api.github.com/repos/rust-lang/cargo/issues/6100/comments","events_url":"https://api.github.com/repos/rust-lang/cargo/issues/6100/events","html_url":"https://github.com/rust-lang/cargo/issues/6100","id":364115234,"node_id":"MDU6SXNzdWUzNjQxMTUyMzQ=","number":6100,"title":"--target-dir and --out-dir","user":{"login":"withoutboats","id":9063376,"node_id":"MDQ6VXNlcjkwNjMzNzY=","avatar_url":"https://avatars2.githubusercontent.com/u/9063376?v=4","gravatar_id":"","url":"https://api.github.com/users/withoutboats","html_url":"https://github.com/withoutboats","followers_url":"https://api.github.com/users/withoutboats/followers","following_url":"https://api.github.com/users/withoutboats/following{/other_user}","gists_url":"https://api.github.com/users/withoutboats/gists{/gist_id}","starred_url":"https://api.github.com/users/withoutboats/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/withoutboats/subscriptions","organizations_url":"https://api.github.com/users/withoutboats/orgs","repos_url":"https://api.github.com/users/withoutboats/repos","events_url":"https://api.github.com/users/withoutboats/events{/privacy}","received_events_url":"https://api.github.com/users/withoutboats/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":2,"created_at":"2018-09-26T16:32:26Z","updated_at":"2018-09-26T18:56:28Z","closed_at":null,"author_association":"CONTRIBUTOR","body":"I noticed that `cargo build` has two subcommands, both added this year. I believe this accurately describes their behavior:\r\n\r\n* `--target-dir`: Replaces `$PWD/target` with this directory (e.g. a debug build will be built into `target-dir/debug`). Stable flag, added in April 2018. #5393 #5308. Mimicks the behavior of `CARGO_TARGET_DIR`\r\n* `--out-dir`: Things will be built into `$PWD/target` as normal, but copies some of the artifacts into the directory specified by `out-dir` (not a profile specific subdirectory). Unstable flag, added in March 2018.  #5203  #4875. Mimicks the behavior of `OUT_DIR`.\r\n\r\n(I'm not 100% certain I've accurately described their behavior in relationship to the profile specific subdirectories.)\r\n\r\n--out-dir is still unstable, but --target-dir was instantly stabilized (by mistake, I believe).\r\n\r\nI can't help but notice that these two flags do very similar things! They also seem to have been designed for very similar purposes (build integration, the meson project is mentioned specifically in both of them).\r\n\r\nI'm not certain I agree that either of them should have been added as flags (an argument is made that flags are better than env vars, and while I agree in principle for *user oriented* APIs, I don't think that build system integration is a *user oriented* API in the relevant sense), but I'm definitely suspicious of having both of these very similar flags provided. Since target-dir is stable, I'm not sure if there's an available avenue to unify these flags other than just only providing target-dir.\r\n\r\ncc @rust-lang/cargo"},"comment":{"url":"https://api.github.com/repos/rust-lang/cargo/issues/comments/424830873","html_url":"https://github.com/rust-lang/cargo/issues/6100#issuecomment-424830873","issue_url":"https://api.github.com/repos/rust-lang/cargo/issues/6100","id":424830873,"node_id":"MDEyOklzc3VlQ29tbWVudDQyNDgzMDg3Mw==","user":{"login":"withoutboats","id":9063376,"node_id":"MDQ6VXNlcjkwNjMzNzY=","avatar_url":"https://avatars2.githubusercontent.com/u/9063376?v=4","gravatar_id":"","url":"https://api.github.com/users/withoutboats","html_url":"https://github.com/withoutboats","followers_url":"https://api.github.com/users/withoutboats/followers","following_url":"https://api.github.com/users/withoutboats/following{/other_user}","gists_url":"https://api.github.com/users/withoutboats/gists{/gist_id}","starred_url":"https://api.github.com/users/withoutboats/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/withoutboats/subscriptions","organizations_url":"https://api.github.com/users/withoutboats/orgs","repos_url":"https://api.github.com/users/withoutboats/repos","events_url":"https://api.github.com/users/withoutboats/events{/privacy}","received_events_url":"https://api.github.com/users/withoutboats/received_events","type":"User","site_admin":false},"created_at":"2018-09-26T18:56:28Z","updated_at":"2018-09-26T18:56:28Z","author_association":"CONTRIBUTOR","body":"> I do agree that for most of the users, interacting with Cargo's CLI, these flags are irrelevant. However, this could be said about some other flags as well, like --manifest-path, --message-format, --build-plan, --frozen, --locked. Perhaps we should hide such \"useful in very specific circumstances\" flags from cargo cmd --help by default?\r\n\r\nI am unhappy with the UX of having all of these flags also. For a long time we've been creeping in the direction of having flags to customize every user visible aspect of the behavior, because this has been how CLI tools traditionally handle users wanting to customize their behavior. However, I think this has a bad UX overwhelming, because it makes the tool overwhelming and ultimately makes all of the flags undiscoverable. I think hiding these tools from `--help` unless you pass another flag  is a half measure, which improves the situation but is probably not the best solution.\r\n\r\nI think a preferable approach to what we've done would be to provide some lower level command which takes as many flags as you want and can be used to build up the user-oriented commands like `cargo build`, `cargo run`, and `cargo test`, but with all of the flags to customize the precise nature of its operations. The higher level commands could be defined in terms of that lower level command, and people writing very bespoke integrations can also build their own build command out of it.\r\n\r\nSo I noticed a few days ago that when I ran `cargo build --help` it went beyond the length of my terminal. This surprised and concerned me, so I took statistics of how `cargo build --help`'s output has grown over time:\r\n\r\n![image](https://user-images.githubusercontent.com/9063376/46101457-43378000-c1cc-11e8-9951-50046a604630.png)\r\n\r\nIt was in the process of investigating how the flags to cargo build had proliferated that I noticed these two flags. I think there's a larger problem here, but these two flags in particular have such similar behavior that keeping them both has unique negative UX consequences aside from the general concern. From the `--help` output I could not understand how they were different, and I don't think their names indicate that the most material difference between them is that one excludes the intermediate artifacts. Its the kind of customization creep that makes me groan and turn to stack overflow instead whenever I try to read the man pages of any of the standard UNIX utilities: their man pages are an information overload that make it too difficult to learn things.\r\n\r\nAn obvious way to help resolve their close similarity is to clarify the differences in the `--help` output. But as we've already touched on, these are not useful for most users, and so in the common case these two commands are both cruft I am trying to sort through to figure out the flag I actually want - increasing the amount of time we dwell on them makes the situation worse. So I don't think that would be a solution either."}}
{"actor":{"display_login":"withoutboats"}}