jeromeetienne / nmod

node_modules manager
9 stars 1 forks source link

proxy #1

Closed dvv closed 13 years ago

dvv commented 13 years ago

Please, let us take care of our brothers who sit behind firewalls ;)

--- nmod.orig   2011-03-10 06:36:16.000000000 -0500
+++ nmod    2011-03-10 06:32:58.000000000 -0500
@@ -51,6 +51,13 @@
            path    : url.pathname,
            headers: {}
        };
+  if (process.env[protocol+'_proxy']||process.env.http_proxy) {
+    var proxy = require('url').parse(process.env[protocol+'_proxy']||process.env.http_proxy);
+    options.headers.host = options.host;
+    options.port = proxy.port || 80;
+    options.host = proxy.hostname;
+    options.path = urlStr;
+  }
        //console.log("fetching", urlStr)
        var req = require(protocol).request(options, function(res) {
            var contentLength   = parseInt(res.headers["content-length"], 10)

Best regards, --Vladimir

jeromeetienne commented 13 years ago

thanks! i will include it.

can you explain why you are repeating "host" in options.headers when it is already in options.hosts ?

On Thu, Mar 10, 2011 at 12:38 PM, dvv < reply@reply.github.com>wrote:

Please, let us take care of our brothers who sit behind firewalls ;)

--- nmod.orig 2011-03-10 06:36:16.000000000 -0500 +++ nmod 2011-03-10 06:32:58.000000000 -0500 @@ -51,6 +51,13 @@ path : url.pathname, headers: {} };

  • if (process.env[protocol+'_proxy']||process.env.http_proxy) {
  • var proxy = require('url').parse(process.env[protocol+'_proxy']||process.env.http_proxy);
  • options.headers.host = options.host;
  • options.port = proxy.port || 80;
  • options.host = proxy.hostname;
  • options.path = urlStr;
  • } //console.log("fetching", urlStr) var req = require(protocol).request(options, function(res) { var contentLength = parseInt(res.headers["content-length"], 10)

Best regards, --Vladimir

https://github.com/jeromeetienne/nmod/issues/1

dvv commented 13 years ago

Hardly ;) It's just the pattern that works. I keep hoping they take it in master for http[s].request() someday, thus making this hack unneeded.

BTW, have you considered bundling all dependencies (of a number of packages) into a single node_modules, so that to reuse them?

jeromeetienne commented 13 years ago

ok included :) https://github.com/jeromeetienne/nmod/commit/28d6960a6c235897f79178852e65f5fa9926e1e0

im not sure what you mean by bundling a single node_modules directory. can you explain ?

You can tgz your node_modules and copy it elsewhere, it will work the same way. so once nmod installed stuff in node_modules. you can just deply the whole project, without need to rerun nmod.

On Thu, Mar 10, 2011 at 1:23 PM, dvv < reply@reply.github.com>wrote:

Hardly ;) It's just the pattern that works. I keep hoping they take it in master for http[s].request() someday, thus making this hack unneeded.

BTW, have you considered bundling all dependencies (of a number of packages) into a single node_modules, so that to reuse them?

https://github.com/jeromeetienne/nmod/issues/1#comment_855651

dvv commented 13 years ago

I mean: nmod install pkg --> node_modules/pkg + node_modules/pkg/node_modules/pkg_dep1 + ... node_modules/pkg/node_modules/pkg_dep1/..../node_modules/ ..../node_modules/..../node_modules/pkg_dep1_dep_N

could be flatten so that all deps of any package sit in one node_modules/ beside the project, w/o the deep hierarchy. That is how I've been doing that: https://github.com/dvv/simple/blob/master/install

jeromeetienne commented 13 years ago

ok got it. what would be the advantages ? to make it smaller on disk ? how to handle the version issue. like one package requires superdep-v1 and another package requires superdep-v2 how to handle this conflict ? i think this could be done with a "nmod gc"...

On Thu, Mar 10, 2011 at 1:55 PM, dvv < reply@reply.github.com>wrote:

I mean: nmod install pkg --> node_modules/pkg + node_modules/pkg/node_modules/pkg_dep1 + ... node_modules/pkg/node_modules/pkg_dep1/..../node_modules/ ..../node_modules/..../node_modules/pkg_dep1_dep_N

could be flatten so that all deps of any package sit in one node_modules/ beside the project, w/o the deep hierarchy. That is how I've been doing that: https://github.com/dvv/simple/blob/master/install

https://github.com/jeromeetienne/nmod/issues/1#comment_855734

dvv commented 13 years ago

not only smaller, but one could have symlinked a git clone and have all dependencies upgraded. But I agree on possible version clash. Just never relied on npm and prefer to work with current masters.

Thanks. Closing...

--Vladimir

jeromeetienne commented 13 years ago

i talked with isaacs about modifying package.json dependancies field. to support git url in dependancy would result in a packager which may be pure git.

but isaacs is not too hot on pure git packager

On Thu, Mar 10, 2011 at 2:02 PM, Jerome Etienne jerome.etienne@gmail.comwrote:

ok got it. what would be the advantages ? to make it smaller on disk ? how to handle the version issue. like one package requires superdep-v1 and another package requires superdep-v2 how to handle this conflict ? i think this could be done with a "nmod gc"...

On Thu, Mar 10, 2011 at 1:55 PM, dvv < reply@reply.github.com>wrote:

I mean: nmod install pkg --> node_modules/pkg + node_modules/pkg/node_modules/pkg_dep1 + ... node_modules/pkg/node_modules/pkg_dep1/..../node_modules/ ..../node_modules/..../node_modules/pkg_dep1_dep_N

could be flatten so that all deps of any package sit in one node_modules/ beside the project, w/o the deep hierarchy. That is how I've been doing that: https://github.com/dvv/simple/blob/master/install

https://github.com/jeromeetienne/nmod/issues/1#comment_855734

dvv commented 13 years ago

Revolutionary things always end in being conservative. That's why nmod per se, I guess ;)