I'm in #python hell:
root ~ # /usr/local/bin/twine --version
twine version 1.15.0
user ~ # /usr/local/bin/twine --version
twine version 1.9.1
Same computer, new shells.
Have you consulted this?:
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 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
@jesse_m Thanks for your answers!
If you use "~/.venvs/$PROJECT" you should end up with *one* venv and not with multiple as you were mentioning. Shouldn't it be ""~/$PROJECT/.venvs/"?
If not, what was your rationale to share one venv with multiple projects?
@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.
@jesse_m I found https://docs.python-guide.org/dev/virtualenvs/ which explained more things to me. So far, tutorials listed $project == virtualenvironment. However, the subdir "venv" (by convention) eases pain a lot.
My current issue with twine could be solved using a new environment via "virtualenv". Let's test some envs then... 😉
Thanks for your support!
@publicvoit great let me know how it goes!
The social network of the future: No ads, no corporate surveillance, ethical design, and decentralization! Own your data with Mastodon!