-
Notifications
You must be signed in to change notification settings - Fork 464
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
Added json option to env command #800
Conversation
🦋 Changeset detectedLatest commit: 456093f The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm having some refactoring questions/suggestions here that I would love to know your input on. But on the other side, I wonder: should we have a support for --shell=nu[shell]
? the json
implementation can allow implementing this on userland easier, but maybe we should bake this knowledge into fnm and test it properly to make other features like use-on-cd
work?
src/commands/env.rs
Outdated
/// Print JSON instead of shell commands. | ||
#[clap(long)] | ||
json: bool, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should probably make it broader, so --output=json
is preferable. --output=json
conflicts with --shell=ANY
which can be declared with #[clap(conflicts_with = "shell")]
That being said, --shell=...
is practically --output=...
, right? so maybe we can leverage --shell=
to be used as --shell=json
? Kinda ugly naming but does not break and does not introduce another API complexity?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah I didn't know about conflicts_with
. Thanks!
Haha I almost did --shell=json
. Maybe deprecating --shell
and replace it with --output
? That reads well in my head.
fnm env --output=bash
Then for compatbility sake just have --shell
map to --output
? Is there an option for that in clap
?
ah and by the way, thanks for stepping up and making a PR. I really appreciate your contribution. It's not something I take for granted 🙏 |
Thanks for the review and improvement suggestions! I'll be honest my decision making was mainly driven by my lack of experience with rust haha. I 100% agree adding nushell to the |
re:
(off topic, I'm using lists on github any time I want to link to an issue just to have the nice formatting they do on lists. FORMATTING ISSUES EVERYWHERE IN GITHUB WEN) |
I built fnm in Rust when I had zero experience in Rust, I want to refactor so much of the current code but I have no time 😜 you're doing good 🙏 |
@zaucy I took the liberty to fix conflicts so I'll merge this finally. Sorry it took so long. |
Ayy! Love that |
in Windows PowerShell, seems like .ps1 is mandatory, otherwise it does not run the script. In Windows PowerShell, it outputs ASCII by default. This commit makes it output UTF8 without BOM when redirecting output.
Co-authored-by: Gal Schlezinger <gal@spitfire.co.il>
Main motivation for this PR is to make the nushell experience better (#463). Taken from one of the suggestions in the comments I added a
--json
option.