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

Potential crates to recommend #6

Open
epage opened this issue Oct 16, 2019 · 5 comments
Open

Potential crates to recommend #6

epage opened this issue Oct 16, 2019 · 5 comments

Comments

@epage
Copy link
Collaborator

epage commented Oct 16, 2019

(sorry, needing to rush again or else I'd create a PR)

Immediately useful:

Could be refactored to be useful

@epage
Copy link
Collaborator Author

epage commented Oct 16, 2019

I'm unsure whether cargo release and clog/jilu (changelog generation) would be useful to refactor into xtasks.

@matklad
Copy link
Owner

matklad commented Oct 16, 2019

I think in a world where Cargo has per-machine (as opposed to per-project) binary cache, I personally would certainly prefer cargo release to be an xtask, rather than a custom subcommand. Today, the situation is less clear...

@epage
Copy link
Collaborator Author

epage commented Oct 16, 2019

I personally would certainly prefer cargo release to be an xtask, rather than a custom subcommand

I'm seeing the potential for that now and am really liking it. While there are benefits to pushing people to a standard workflow, there are some things that can't be standardized (like changelog practices) and giving people a toolbox for how to release that they can build up as needed is a really interesting idea.

@epage
Copy link
Collaborator Author

epage commented Oct 17, 2019

clap-cargo would also be a useful crate for xtasks with custom extensions, like imitating cargo's workspace flags.

@matklad
Copy link
Owner

matklad commented Oct 17, 2019

I am not actually sure: clap provides high-quality argument parsing, at the cost of high compile times. I think for xtasks, super-fancy arg parsing is not required, so something like pico-args might be a better choice

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

No branches or pull requests

2 participants