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

Login issues #487

Merged
merged 2 commits into from
Jan 11, 2019
Merged

Login issues #487

merged 2 commits into from
Jan 11, 2019

Conversation

danwilhelm
Copy link
Member

  1. Fixes Issue Empty input prompt when 'login' #486: Empty input prompt when login.
  2. Fixes login arguments being accidentally merged together when spawning npm adduser.

See the text of each commit for more details.

  • [✅] You have the latest version of rustfmt installed
  • [✅] You ran cargo fmt on the code base before submitting
  • [✅] You reference which issue is being closed in the PR text

Issue rustwasm#484.

PR392 inadvertantly replaced the `login` interactive process spawner
with
`child::run`, which is hard-coded to buffer stdout/stderr. This caused
`login` to become essentially unusable; the user could no longer see
interactive input prompts or error messages displayed by `npm adduser`.

The code was not directly reverted because the previous version:
1. Returned Error instead of failure::Error. (Updated to use
`bail!`, which is consistent with `publish`.)
2. Displayed all stderr only upon exit, rather than interactively
displaying it. This led to repeated interactive prompts without
informing the user why. (Updated to use `status()` which inherits
stdin/stdout/stderr by default.)
3. Did not provide logging. (Now duplicates the logging in
`child::run`.)
All arguments were passed to `arg` inside one string when building a
`Command`. However, using the `arg` function, "only one argument can be
passed per use." This caused all arguments accidentally to be appended
to the registry URL. For example: After a successful login with a
provided `--auth_type`, the success message incorrectly displayed:
"Logged in as asf on https://registry.npmjs.org/%20--auth_type=Basic."
The space (%20 in hex) was caused by adding a fixed space before each
additional argument.

This commit pushes all arguments onto a `Vec<String>`. Then, the `args`
function adds the arguments separately to the command. This removes the
need to prepend spaces to each argument. Alternatively, `arg` could have
been used throughout to build the command argument-by-argument. However,
using `args` partitions the code more neatly into two distinct sections.
@ashleygwilliams
Copy link
Member

hi @danwilhelm ! thanks so much for taking this on! looks good to me- want to test locally before approving. tagging in @fitzgen due to the mentioned limitations of the child process abstraction- curious what his thoughts are!

@danwilhelm
Copy link
Member Author

@fitzgen It would be nice to keep all of the process code in child.rs. So alternatively, I could perhaps add a child::run_interactive to child.rs? I was hesitant to add a flag to child::run, since it is already a bit complex and seems wholly designed to accumulate the outputs.

Note the solution I proposed here does not log npm adduser outputs and the user's interactive responses, which was one intention of child::run. However, from experience in another language, this might be difficult to do while still keeping it interactive and bug-free.

Copy link
Member

@fitzgen fitzgen left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This LGTM!

In general, I hate interactive CLI tools, and would prefer that if they need more info, just exit non-zero and say "use --whatever flag to specify this info we are missing", but since this is npm doing this, and we are wrapping npm here, we don't really have much choice.

Thanks for the PR @danwilhelm!

@fitzgen
Copy link
Member

fitzgen commented Jan 11, 2019

@fitzgen It would be nice to keep all of the process code in child.rs. So alternatively, I could perhaps add a child::run_interactive to child.rs? I was hesitant to add a flag to child::run, since it is already a bit complex and seems wholly designed to accumulate the outputs.

I'm not sure what child::run_interactive would do that the normal std doesn't already. child::run is all about making sure that we log child output correctly, but running interactively kind of side steps that, so I don't think there is much to be done.

If I'm missing something, please file a follow up issue with suggestions and we can take the discussion there! :)

Copy link
Member

@ashleygwilliams ashleygwilliams left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i feel 50/50 about a refactor of the child process stuff, login is a p unique use case re how we wrap commands. i think we could hold off until we discover ourselves wrapping another interaction command (potentially never).

@fitzgen fitzgen merged commit 35cabb6 into rustwasm:master Jan 11, 2019
@danwilhelm
Copy link
Member Author

I agree with both of you, which is why I implemented it as-is! Indeed, a new function child::run_interactive would do nothing more than call the normal std function.

@danwilhelm danwilhelm deleted the login-issues branch January 13, 2019 22:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants