Hacker News Reader

Comment by pronlover723 | Hacker News Reader

For me, before I even get to packaging, I hit the install/environment issue with python. Python, by default, wants to be installed at a system level and wants libraries/packages to be at a system level.

That shit has to stop. The default needs to be project local installs. Node might have issues but one thing they got right is defaulting to project local installs vs python where you need various incantations to get out of the default "globals" and you need other incantations to switch projects.

View on HN

Lucky for you, there's a new PEP proposing just that: https://discuss.python.org/t/pep-704-require-virtual-environ... Written by the author of this blog post no less!

However, you'll find that as with all packaging discussions there are people opposing it, because their workflow doesn't match yours and they don't want to change how they work. We, as a community, need a way to resolve such stalemates or I fear we won't make much headway

We need some person, a nice person, a benevolent person, who could some how tell other people what to do, dictate it if you will, and it would be best if they could keep up this job for the rest of his or her life. We’ll call them, the Friendly Language Uncle.

I’d prefer a crazy aunt to a creepy uncle… but maybe let’s leave family out of it altogether.

Parent is referring to a long-running (but somewhat obscure at this point unfortunately) joke

https://peps.python.org/pep-0401/

I know. I was trying to say "fuck the patriarchy" with a bit more color.

My solution to this problem has been … to stop using python as a universal tool for all things and instead use other tools purpose built for those purposes.

Unfortunately (or not) that basically means no more python. Because it is definitely a “Jack of all trades, master of none”.

Focusing on programming languages that just want to be programming languages and not also a system service makes life so much better. You end up using languages that produce self-contained, easily shippable binaries, or languages with easily embeddable runtimes, instead of trying to write code that has to somehow survive in a “diverse ecosystem”, which generally makes it overly bloated and brittle as it grows so many appendages to solve so many orthogonal incompatibilities it comes to resemble enterprise open source…

There’s a competing and saner PEP that actually proposes local package directories (which are not venvs): https://discuss.python.org/t/pep-582-python-local-packages-d...

You can do this now by creating a Python virtual environment[0]. Then you can package your project with a requirements file and some instructions on its use. I use Python VENV often, and it works really well.

[0] https://realpython.com/python-virtual-environments-a-primer/

Apparently you missed the point. local needs to be the default. Not some magic incantation

In node

    cd projectFoo
    # do stuff, node uses packages local to projectFoo
    cd ../projectBar
    # do stuff, node uses packages local to projectBar

There is no "activation", the default is it just works.

Installing packages local to the project is also the default.

Activating virtualenvs isn't necessary. In every python project I work in, I do

    $ cd projectFoo
    $ ./ve/bin/python whatever...

(more realistically, it's `make whatever` which then builds the virtualenv into `./ve` if needed, pip installs required packages into it, and runs the command).

Yes, I agree that it would be nice if the default behaviour of `pip install -r requirements.txt` was to install it in an isolated virtualenv specific to that project, but it's not also not like it's completely impossible magic.

This is the important difference. Scripting languages should default to examining the current directory and then its parent directory etc. to find the resources they need. Python doesn't have this default and probably can't change at this point.

The Debian dist-packages/site-packages mechanism alleviates a lot of the problems with dependency hell and clobbering from packages needing to be installed. It's a shame it hasn't been embraced by mainline Python. A case of perfect being the enemy of good. Instead we get the chaos of pyproject as the next great thing.

Another lucky winner: https://peps.python.org/pep-0668/

This PEP is meant to ensure you don't clobber your Linux distro's base environment and break key OS applications.

Also, this problem doesn't exist on e.g. Windows, where there is no OS installed python to clobber. Other folks have taught themselves to always use virtual environments for this very reason and therefore don't share your problem.

Hence, there are tutorials out there that don't talk about your problem and tools exist where the default behavior might be dangerous on your Linux distro.

Reply on news.ycombinator.com