Remix clone Hacker News

Ah, but that would require that the python interpreter look first in the local directory in case there's a virtualenv there, which would mean your system could break depending on which directory you ran bits of it from. Less than ideal.

It's better all round to just assume that unless you're building something to be a part of the system itself, that the system interpreters just aren't for you. There's a special case for shells where they're actually UI, but I've seen so much effort wasted over the years trying to let system interpreters do double-duty as both system tools and development environments that I've come to the conclusion that it's simply not worth the hassle.

▲ j1elo 6 days ago | parent [-]

That's the idea, yes. Do you have by any chance any experience with Node.js? Running a JS script is usually done in two steps:

  1. npm install
  2. node my_script.js

First one downloads and installs all dependencies listed in a package.json file into a node_modules local subdir. This is equivalent to creating a pip venv, activating the venv, and running pip install against a requirements.txt file.

Second one runs the interpreter with the script file and against the locally downloaded dependencies.

I.e. the local env dirs in Node.js are not a suggestion that you need to learn about, make choices, and actually use; they are just how the tool works by default, which makes the experience of using Node.js with NPM by far much better and less confusing than the default experience of using Python with PIP.

▲

regularfry 6 days ago | parent [-]

I have years of painful experience with node.js, yes. The critical difference between node and python is that there are no system-provided scripts on my system which have `#!/usr/bin/node` as a first line.

There are a load of scripts with `#!/usr/bin/python` (or similar) in `/bin`, which means package resolution can't look first in a local subdir otherwise all bets are off. Again: your system will break depending on which directory you run bits of it from. The system-provided process would be loading dependencies that it was not tested against. In case this is unclear, you do not want that to happen. It would be bad. On my system I can see python scripts involved in driver management. I do not want them to do unexpected things. It would be bad.

Python package management is a mess in lots of ways, but this particular choice isn't one of them.

▲

fragmede 6 days ago | parent [-]

> which means package resolution can't look first in a local subdir

Sure it can, it's just a matter of examining where it's being run from.

I wrote python-wool to load packages from a venv if it finds one.

https://github.com/fragmede/python-wool

	▲	regularfry 6 days ago \| parent [-]
		Yep. That comes under the category of "not default". Although now you've pointed it out I'll probably be using it.