Hacker News Reader

Comment by pjc50 | Hacker News Reader

Python remains a mess for these use cases because it does not have packages.

It has a very specific filesystem layout that it calls a package, but this is not a first class citizen; it has a packaging format called "wheel" that is now used for distribution, and that can contain native libraries. That currently mostly handles the distribution of compiled libraries for multiple platforms, but only within the traditional venv-style setup. Being able to ship interpreter+venv+launcher would go a long way towards providing a native-ish experience.

A step beyond that would be being able to distribute a "virtual filesystem" containing a whole tree of python compiled as .pyc, appended to a native executable containing the interpreter and linked against the required native libraries already.

View on HN

I'm a huge fan of https://github.com/indygreg/python-build-standalone which provides Python builds that CAN be moved around and work independently of any other Python installation.

I used that for my own Python+Electron app, which I wrote about here: https://til.simonwillison.net/electron/python-inside-electro...

Venvs not being able to be moved to other directories is such a PITA.

They are though, at least on Windows, I’ve moved them before. The whole Lib/ tree was independent of the venv’s path, it’s only the “activate” script that hard-codes a full path.

Since venvs on Linux symlink to the system’s Python executable, they should also work after moving.

> They are though, at least on Windows, I’ve moved them before. The whole Lib/ tree was independent of the venv’s path, it’s only the “activate” script that hard-codes a full path.

So, if activate.ps1 (and the other scripts for other shells) were updated to dynamically identify their own location rather than hardcoding the path, they’d be fully portable? Seems to be a fairly simple update.

> Since venvs on Linux symlink to the system’s Python executable

Hopefully, the executable with which they were created, not the system executable except where they happen to be the same.

> So, if activate.ps1 (and the other scripts for other shells) were updated to dynamically identify their own location rather than hardcoding the path, they’d be fully portable? Seems to be a fairly simple update.

I don't think the maintainers have gotten a request to do that. Personally I use a more complicated launcher because I need to set things like environment variables in my deployments, but a venv is almost an out-of-the-box relocatable Python environment. It's when you need to protect/compile your code that things get messy.

>> Since venvs on Linux symlink to the system’s Python executable

>Hopefully, the executable with which they were created, not the system executable except where they happen to be the same.

When you call /usr/bin/pythonx.y -m venv ./myenv, ./myenv/bin/python will link to /usr/bin/pythonx.y. Since there aren't many reasons to use a Python version not installed by the package manager, I call these the "system's Python executables", but sure, it can also point to /opt if you installed Python there.

> it’s only the “activate” script that hard-codes a full path.

So…they aren’t then.

They are in the sense that anything one would want to do with a venv, they can do with trivial effort. You don't need the activate script, you can just set PATH, PYTHONHOME and/or PYTHONPATH and be done with it.

Reply on news.ycombinator.com