[Rubygems-developers] I can see through my proxy!
chad at chadfowler.com
Wed Apr 14 09:35:35 EDT 2004
On 13/4/2004, at 9:47 PM, Gavin Sinclair wrote:
>>> Now, my related questions:
>>> 1. What does the --http-proxy option do?
>> You can actually specify your proxy here instead of using the
>> environment variable.
> Got it. And it takes precedence, right?
Yes (if it doesn't, it's a bug)
>>> 2. It seems superfluous to me; can we get rid of it?
>> It's like having CVSROOT and cvs -d to me. It doesn't seem
>>> 3. Can we have --http-proxy and --no-http-proxy if we want
>>> to temporarily disable proxy access? (i.e. neither option
>>> takes an argument.)
>> Something like this might be nice, though you could just null out the
>> environment variable (if you're using one), and the absence of
>> --http-proxy would disable proxy access.
> Nulling out env vars, in general, is not "nice", I'm sure you agree. A
> while ago, you mentioned wanting to be able to disable proxy access for
> testing. Also, I work in proxied and non-proxied environments. I
> use --no-http-proxy in the latter so I can just keep the variable set.
I agree, but I don't tend to use the ENV variables. :)
>>> 4. Perhaps allowing an *optional* argument, e.g.
>>> --http-proxy 'http://www-cache:8000'
>>> is good, but I really can't see why you'd want it.
>> I prefer not to muck around with environment variables most of the
>> time. When given a command line option vs. an environment variable, I
>> almost always use the command line version. I can't really defend it,
>> but I'm at least one user who wants it. :)
> OK, I'll submit a patch tonight (my time) that allows the following:
> --http-proxy PROXY # Overrides environment variables
> --http-proxy # Uses environment variables
> --no-http-proxy # Disables proxy access
> The second one seems useless at first glance, because you can just
> it out and the variable will be honoured. However, it is useful to
> override a --no-http-proxy option (for instance, in the config file).
> Any objections?
You're right about the second one, but I see your point. No objections
>>> # And I really wish 'rdict' was available as a gem...
>> That's probably easily solved. :)
> I sent an email to the author already, offering help.
More information about the Rubygems-developers