4 ms·

For what it's worth, python -m venv venv source venv/bin/activate pip install -r requirements.txt has never let me down and doesn't abstract away

For what it's worth, python -m venv venv source venv/bin/activate pip install -r requirements.txt has never let me down and doesn't abstract away anything.

BiteCode_dev 3y ago
That's pretty much the procedure the article link to in the intro, but with some additional subtleties on how to source and run python.
pera 3y ago
That might work for a subset of projects, but try that with anything that does for instance numerical analysis stuff, like machine learning. There is a reason why Conda is a requirement for so many Python projects.
roel_v 3y ago
In your example, one of the abstractions is 'what Python does it use'. Because I'm dealing with this very issue right now, distributing a simple Python tool to a Windows end user, and they're on heavily managed government machines and it turns out that their 'python' command invokes a python.exe somewhere on a network drive and for some reason the '-m venv venv' fails, which then causes all the rest to fail as well of course. Now I don't know yet if this network thing is really the root cause, I've just received some error logs that showed this this morning, so I'm on another round of trying to remote debug this, via email, with someone who is (while patient and willing) not a Python programmer. Python packaging is such a ridiculous PITA, it's laughable if it wasn't so sad. I tried nuitka as suggested upthread, and send my customer a single binary to try, let's see if it works.
- deleted 3y ago
  [deleted]
- aragilar 3y ago
  It's probably Python 2, which won't have venv.
dagw 3y ago
Except many python packages have started to move away from requirements.txt to pyproject.toml files, so you have to deal with that. Plus now you have to either remember where you put all your venvs and which tool is where or do weird hacky things with $PATH.
- nerdponx 3y ago
  The recommended process nowadays is to use Pipx which just creates a fresh venv for each tool.
  - MiguelX413 3y ago
    That doesn't work for development but I agree that it's extremely useful for using Python projects.
bad_alloc 3y ago
If the provider of requirements.txt did their homework, yes. However I often got incomplete requirements files or they contained mutually incompatible versions (numba and numpy soemtimes dont get along). (This is in academia btw)
crabbone 3y ago
> has never let me down Oh you sweet summer child. You are like those people who want to discover why make backups the hard way.
nyberg 3y ago
What if there are native dependencies required? It starts to get a bit hairy whenever something cannot be provided by pip alone. Shipping binrary libs is not a suitable option.
- nerdponx 3y ago
  [dead]
fictorial 3y ago
I use a variation of this with direnv and asdf and it's fine, no problems. asdf install python 3.11.0 asdf local python 3.11.0 # .tool-versions python -m venv .venv echo >.envrc <<EOF export VIRTUAL_ENV=.venv export PATH=.venv/bin:$PATH EOF direnv allow . Now I just `cd` to project directories and I'm good to go.

For what it's worth, python -m venv venv source venv/bin/activate pip install -r requirements.txt has never let me down and doesn't abstract away anything.

BiteCode_dev 3y ago

That's pretty much the procedure the article link to in the intro, but with some additional subtleties on how to source and run python.

pera 3y ago

That might work for a subset of projects, but try that with anything that does for instance numerical analysis stuff, like machine learning. There is a reason why Conda is a requirement for so many Python projects.

roel_v 3y ago

In your example, one of the abstractions is 'what Python does it use'. Because I'm dealing with this very issue right now, distributing a simple Python tool to a Windows end user, and they're on heavily managed government machines and it turns out that their 'python' command invokes a python.exe somewhere on a network drive and for some reason the '-m venv venv' fails, which then causes all the rest to fail as well of course. Now I don't know yet if this network thing is really the root cause, I've just received some error logs that showed this this morning, so I'm on another round of trying to remote debug this, via email, with someone who is (while patient and willing) not a Python programmer. Python packaging is such a ridiculous PITA, it's laughable if it wasn't so sad. I tried nuitka as suggested upthread, and send my customer a single binary to try, let's see if it works.

deleted 3y ago
[deleted]
aragilar 3y ago
It's probably Python 2, which won't have venv.

dagw 3y ago

Except many python packages have started to move away from requirements.txt to pyproject.toml files, so you have to deal with that. Plus now you have to either remember where you put all your venvs and which tool is where or do weird hacky things with $PATH.

nerdponx 3y ago
The recommended process nowadays is to use Pipx which just creates a fresh venv for each tool.
- MiguelX413 3y ago
  That doesn't work for development but I agree that it's extremely useful for using Python projects.

bad_alloc 3y ago

If the provider of requirements.txt did their homework, yes. However I often got incomplete requirements files or they contained mutually incompatible versions (numba and numpy soemtimes dont get along). (This is in academia btw)

crabbone 3y ago

> has never let me down Oh you sweet summer child. You are like those people who want to discover why make backups the hard way.

nyberg 3y ago

What if there are native dependencies required? It starts to get a bit hairy whenever something cannot be provided by pip alone. Shipping binrary libs is not a suitable option.

nerdponx 3y ago
[dead]

fictorial 3y ago

I use a variation of this with direnv and asdf and it's fine, no problems. asdf install python 3.11.0 asdf local python 3.11.0 # .tool-versions python -m venv .venv echo >.envrc <<EOF export VIRTUAL_ENV=.venv export PATH=.venv/bin:$PATH EOF direnv allow . Now I just `cd` to project directories and I'm good to go.