4 ms·

Man, global system-wide installations that require admin rights by default? That's certainly something! Quite the stark comparison to Node.js and npm, where eve

by Daiz 13y ago

Man, global system-wide installations that require admin rights by default? That's certainly something! Quite the stark comparison to Node.js and npm, where everything is installed locally into the current directory (under node_modules) by default, and "global" installation is actually a per-user installation. Tricking pip with virtualenv seems to get you pretty close to what you get by default with npm, albeit still somewhat more clunky. But to be fair, most other package managing solutions seem to pale in comparison to npm :-) Either way, nice article. Now if only most packages weren't still for Python 2... PyPI says it has 30099 packages total, but only around 2104 of them are for Python 3 (according to the number of entries on the "Python 3 Packages"-page[1]). [1] https://pypi.python.org/pypi?:action=browse&c=533&show=all https://pypi.python.org/pypi?:action=browse&c=533&sh...

mixmastamyk 13y ago
pip install --user XXX should get you what you want. Not default but not a huge burden either.
- Daiz 13y ago
  ...Which would be equivalent to npm install -g XXX, whereas to replicate npm install XXX you'd need virtualenv. I don't think there even is an equivalent to pip install XXX without virtualenv with Node/npm (global system-wide installation for all users that requires admin rights).
tomku 13y ago
npm's default for -g is to install to Node's prefix, which is usually /usr or /usr/local. If you want it to install to your home directory, you can set the prefix to somewhere appropriate in your ~/.npmrc, which gives roughly the same behavior as pip's --user flag. Edit: perhaps you changed your .npmrc or set the option via npm and forgot about it? I just checked on a fresh user, and 'npm install -g' definitely tries to install to /usr, just like pip.
- Daiz 13y ago
  I use Windows as my main OS, and by default npm -g installs packages to %AppData%, which is user-specific. I guess it's different on *nix, then.
  - e12e 13y ago
    That sounds broken to me. Then it's no longer -g for global. You do run your app under a different account than your user-account, right? Something like "nodeuser"?
    - Daiz 13y ago
      >You do run your app under a different account No, why would I do something like that on a development box? (Or run web stuff on Windows servers for that matter.) And pretty much the only things I install with -g are useful CLI tools - any code I write will have its dependencies installed locally and listed in package.json for 'npm install'.
      - e12e 13y ago
        It wasn't clear (to me) that this was a development box. And it certainly wasn't something npm could know -- so my point still stands. If there's a way to install packages globally, then they should be globally available -- also on windows. But perhaps this is documented somewhere. As for why you would run stuff on windows, perhaps you were writing an ajax gateway to a legacy system and it made more sense to run the node server on the same machine as the legacy system? (To be clear, I would pity you if that was the case, but you never know ;-)
hcarvalhoalves 13y ago
Are you trolling? The primary use case of npm is quite different. No one installs system-wide npm packages. Virtualenv solves a different problem (create a complete Python environment inside a directory) so you can replicate the various production setups in your machine and develop. It's not a way to avoid admin-privileges to install system software, for that you can just pip install --user, use homebrew, whatever.
- Daiz 13y ago
  >Virtualenv solves a different problem Based on the article I'd say the main reason to use it is so that you can have what amounts to local packages instead of having to rely on global packages (be they system-wide or user-specific). This is what npm does by default - packages are installed locally to node_modules. And for replicating production setups I'd rather take it a step further and use something like Vagrant instead of replicating just one part of the setup (Python).

by Daiz 13y ago

mixmastamyk 13y ago

pip install --user XXX should get you what you want. Not default but not a huge burden either.

Daiz 13y ago
...Which would be equivalent to npm install -g XXX, whereas to replicate npm install XXX you'd need virtualenv. I don't think there even is an equivalent to pip install XXX without virtualenv with Node/npm (global system-wide installation for all users that requires admin rights).

tomku 13y ago

npm's default for -g is to install to Node's prefix, which is usually /usr or /usr/local. If you want it to install to your home directory, you can set the prefix to somewhere appropriate in your ~/.npmrc, which gives roughly the same behavior as pip's --user flag. Edit: perhaps you changed your .npmrc or set the option via npm and forgot about it? I just checked on a fresh user, and 'npm install -g' definitely tries to install to /usr, just like pip.

Daiz 13y ago
I use Windows as my main OS, and by default npm -g installs packages to %AppData%, which is user-specific. I guess it's different on *nix, then.
- e12e 13y ago
  That sounds broken to me. Then it's no longer -g for global. You do run your app under a different account than your user-account, right? Something like "nodeuser"?
  - Daiz 13y ago
    >You do run your app under a different account No, why would I do something like that on a development box? (Or run web stuff on Windows servers for that matter.) And pretty much the only things I install with -g are useful CLI tools - any code I write will have its dependencies installed locally and listed in package.json for 'npm install'.
    - e12e 13y ago
      It wasn't clear (to me) that this was a development box. And it certainly wasn't something npm could know -- so my point still stands. If there's a way to install packages globally, then they should be globally available -- also on windows. But perhaps this is documented somewhere. As for why you would run stuff on windows, perhaps you were writing an ajax gateway to a legacy system and it made more sense to run the node server on the same machine as the legacy system? (To be clear, I would pity you if that was the case, but you never know ;-)

hcarvalhoalves 13y ago

Are you trolling? The primary use case of npm is quite different. No one installs system-wide npm packages. Virtualenv solves a different problem (create a complete Python environment inside a directory) so you can replicate the various production setups in your machine and develop. It's not a way to avoid admin-privileges to install system software, for that you can just pip install --user, use homebrew, whatever.

Daiz 13y ago
>Virtualenv solves a different problem Based on the article I'd say the main reason to use it is so that you can have what amounts to local packages instead of having to rely on global packages (be they system-wide or user-specific). This is what npm does by default - packages are installed locally to node_modules. And for replicating production setups I'd rather take it a step further and use something like Vagrant instead of replicating just one part of the setup (Python).