Follow

I'm in hell:

root ~ # /usr/local/bin/twine --version
twine version 1.15.0

But:

user ~ # /usr/local/bin/twine --version
twine version 1.9.1

🤔
Same computer, new shells.

@publicvoit what does `which python` or `which python3` say in both cases?

@fabian @publicvoit 👆 Yeah, seems like root must be using a different python environment somehow. I've gotten in the habit of setting up a dedicated environment for every new project:

`python3 -m venv /path/to/my/proj/dir/venv`

(Can put it anywhere, proj. dir is just handy) which can then be activated with

`source /path/to/my/proj/venv/bin/activate`

That way anything you install with pip will be self-contained and avoid version problems. (To exit you can just type `deactivate`)

@publicvoit @fabian Ah, it does look like virtualenv is the same thing. The venv dir can go anywhere, and you would need to re-activate it any time you want to work on that project. (Most IDEs will also let you specify the environment for the project too.)

I haven't tested to confirm, but for cron I think you just invoke the venv python directly (stackoverflow.com/a/3287063)

* * * * * cd /path/to/my/project && /path/to/my/venv/bin/python mycode.py

@publicvoit
Have you consulted this?:
imgs.xkcd.com/comics/python_en

Also, yeah that's why I just use virtualenvs for user projects and leave my system python environment alone. Messed that up too many times

@publicvoit Yeah I really like how ocaml and rust do it where they just install to a hidden directory in your $HOME and make switching versions easy.

@publicvoit I could see that being confusing. The way I use it is I have a virtualenv for most large projects. I tend to keep them all in "~/.venvs/$PROJECT". So I have a bunch of virtualenvs. Since that activate script is just changing environment variables you have to do it for each shell. I didn't think about doing it in your bashrc or something though. I think that would mess things up since sometimes you might need to interact with your system's python install

@publicvoit I actually use it both ways. When I have a class of projects that make use of the same required python packages I have a python env that I put there. If I have something very project specific I try and put it in the project's directory and add it to the .gitigore since they aren't very portable and I don't think you'd want that tracked anyways.

Sign in to participate in the conversation
Mastodon

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!