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

Feature request: `gem sources --add` should write new source without hitting the URL first. #1607

Open
jasonkarns opened this Issue May 5, 2016 · 3 comments

Comments

Projects
None yet
4 participants
@jasonkarns
Contributor

jasonkarns commented May 5, 2016

I'm having a problem or would like to suggest a feature.

My current problem is gem sources requiring authentication cannot be added using gem sources --add without including the user:pass authentication components in the URL. This writes private authentication information to ~/.gemrc.

This issue is related to:

  • Network problems
  • Installing a library
  • Publishing a library
  • The command line gem
  • Other

Here are my current environment details:

$ gem env version
2.2.2

I will abide by the code of conduct.

I much prefer to keep the authentication information outside of .gemrc by using bundle config (or more specifically, the BUNDLER_* env vars). Which means the gem source needs to be added to .gemrc without the authentication components. However, doing gem sources --add <source_url_without_auth> fails because the unauthenticated URL returns a 401. I propose that gem sources --add either:

  1. add a flag to disable the preflight check
  2. write the source to .gemrc first and then hit the url, emitting an error message as appropriate and returning the proper error code.

My vote is for option 2.

@drbrain

This comment has been minimized.

Show comment
Hide comment
@drbrain

drbrain May 5, 2016

Member

Historically I've avoided allowing creation of a broken configuration by adding a failing URL to ~/.gemrc because it causes future failures that can be hard for the user to debug.

RubyGems could prompt for username and password (using io/console) or read the value from the environment for both authentication validation and future use.

Member

drbrain commented May 5, 2016

Historically I've avoided allowing creation of a broken configuration by adding a failing URL to ~/.gemrc because it causes future failures that can be hard for the user to debug.

RubyGems could prompt for username and password (using io/console) or read the value from the environment for both authentication validation and future use.

@jasonkarns

This comment has been minimized.

Show comment
Hide comment
@jasonkarns

jasonkarns May 5, 2016

Contributor

Historically I've avoided allowing creation of a broken configuration by adding a failing URL to ~/.gemrc because it causes future failures that can be hard for the user to debug.

Yep, completely understand. I also suspect I'm in the minority in wanting to add an authenticated source url but without including the auth component. Though this does seem strikingly related to #1134 somehow.

RubyGems could prompt for username and password (using io/console) or read the value from the environment for both authentication validation and future use.

This would be an awesome double-win: auth-free gemrc + source-url still fully validated before being written. It's also the most work :/

Contributor

jasonkarns commented May 5, 2016

Historically I've avoided allowing creation of a broken configuration by adding a failing URL to ~/.gemrc because it causes future failures that can be hard for the user to debug.

Yep, completely understand. I also suspect I'm in the minority in wanting to add an authenticated source url but without including the auth component. Though this does seem strikingly related to #1134 somehow.

RubyGems could prompt for username and password (using io/console) or read the value from the environment for both authentication validation and future use.

This would be an awesome double-win: auth-free gemrc + source-url still fully validated before being written. It's also the most work :/

@segiddins

This comment has been minimized.

Show comment
Hide comment
@segiddins

segiddins May 21, 2016

Member

I agree with drbrain on this -- yes, it's the most work, but it's better than allowing something broken to happen. I think we'd accept a PR implementing this :)

Member

segiddins commented May 21, 2016

I agree with drbrain on this -- yes, it's the most work, but it's better than allowing something broken to happen. I think we'd accept a PR implementing this :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment