use a proxy server for deploy and logs commands

[stephanebisson]

No description provided.

[glasser]

Can you give us a hint as to how we can test this (an example of a proxy we can set up, eg)?
And is this really better than doing some sort of proxy autodetection --- are users really going to be aware of their proxy server and want to type it at every command?

[stephanebisson]

I agree, using system's configured proxy would be much more convenient for the users. Also, I think it should be handled lower in the stack, like in the request or http module. I wrote this code because it was just impossible for me to deploy my app. And I submitted the PR because I thought it might help others.

I don't know what you guys did, but *.meteor.com suddenly became unavailable from china ;)

If you don't have acces to a proxy server, I don't know what you can do to test it. You can write a negative test that tries to connect to a proxy that does not exist and then you'll see it fail with an error message that tells you that such proxy was unreachable. But for a positive case, I guess you could install a local proxy server. I believe this one could do: https://github.com/nodejitsu/node-http-proxy

[gschmidt]

@stephanebrisson, thanks for this! I'd like to get it accepted and included in an upcoming release of Meteor. Two things:

1. Could you please fill out the Meteor contributor license agreement at http://contribute.meteor.com?

2. What would you think about looking at an environment variable (named something like METEOR_PROXY, say?) rather than a command-line argument? That way you could set it in your startup script and forget about it. If you prefer that, would you be willing to make the corresponding changes to the pull request?

@glasser, my though on testing is that we could at least do a smoke test by hardcoding a proxy server from the list at http://www.publicproxyservers.com/ into the test.

Autodetection of the system-configured proxy server would definitely be preferable, but I think it's fine for now to merge this as an incremental step forward.

Thanks again!

[stephanebisson]

I think looking at an environment variable instead of a command line
parameter is a good idea. However, I don't really have time to look at it
at the moment. I understand it's just a little change but I'm deep into
another project with a completely different stack right now. I'll try to do
it in the next few weeks.

On Wed, Feb 6, 2013 at 3:16 PM, gschmidt notifications@github.com wrote:

@stephanebrisson, thanks for this! I'd like to get it accepted and
included in an upcoming release of Meteor. Two things:

1. Could you please fill out the Meteor contributor license agreement at
   http://contribute.meteor.com?

2. What would you think about looking at an environment variable (named
   something like METEOR_PROXY, say?) rather than a command-line argument?
   That way you could set it in your startup script and forget about it. If
   you prefer that, would you be willing to make the corresponding changes to
   the pull request?

@glasser https://github.com/glasser, my though on testing is that we
could at least do a smoke test by hardcoding a proxy server from the list
at http://www.publicproxyservers.com/ into the test.

Autodetection of the system-configured proxy server would definitely be
preferable, but I think it's fine for now to merge this as an incremental
step forward.

Thanks again!

—
Reply to this email directly or view it on GitHubhttps://github.com//pull/429#issuecomment-13202686.

[gotwig]

I am still affected. Is there any progress in providing such a proxy variable, or using system variables? :( please I need that for my school network. Also see "Cant update meteor behind a proxy on Linux!"

[n1mmy]

This is now on devel. 3177d9a.