5 ms·
Never had a problem with dependencies in Python. Just keep it simple. When starting a new project: virtualenv venv -p *path-to-python-version-you-want* ./
by michaelmcmillan 8y ago
Never had a problem with dependencies in Python. Just keep it simple.
When starting a new project:
virtualenv venv -p *path-to-python-version-you-want*
./venv/bin/pip install *name-of-package*
When running that project:
./venv/bin/python *name-of-python-file*
Many people don't realize that the venv/bin/ contains all the relevant binaries with the right library path's out of the box.
- Rjevski 8y agoPipenv is a good replacement for the above workflow. It manages your dependencies and virtualenvs.
- michaelmcmillan 8y agoThanks for the tip, but honestly, I don't need another tool.
- AndrewOMartin 8y agoI was of the same mentality, until yesterday when I watched this PyCon video, uploaded 13 May 2018. https://www.youtube.com/watch?v=GBQAKldqgZs https://www.youtube.com/watch?v=GBQAKldqgZs To cut a long story short, if you're happy with virtualenv and pip then that's great, but the idea of pipenv is to replace virtualenv and pip, which means you'll actually have one tool fewer. :)
- beagle3 8y agoGenuine question: does pipenv do anything that [mini]conda doesn't?
- AndrewOMartin 8y agoEverything you need to know about pipenv is in the linked talk. Sorry, I don't know anything about [mini]conda.
- orf 8y agoDoes conda create a lockfile?
- kalefranz 8y agoNot yet. But that's planned. See See https://github.com/conda/conda/issues/7248 https://github.com/conda/conda/issues/7248.
- spapas82 8y agoIs there a reason you don't "activate" your virtualenv? That (with the addition of using mkvirtualenv and friends) is the workflow I use to both dev and prod and am really happy with!
- michaelmcmillan 8y agoI don't like "magic". I don't need anything to hijack PS1 and muck around with my shell.
- spapas82 8y agoFair enough.
- breatheoften 8y agoI heartily agree with this. I really dislike the tools that provide their functionality by mucking around with the shell environment in (essentially random after accounting for platform variations) ways ... Tools like nvm, rvm, ros ... If I can use a solution for managing a development context that doesn't involve mucking around with the shell environment I much prefer it. Configuration via the sourcing of shell scripts is a very fragile interface, doesn't work when with good (ie non-bash) shell, and almost always eventually leads to bugs when some workflow triggers processes in a manner that fails to inherit the shell environment...
- crdoconnor 8y agoI hate the whole idea of activating virtualenvs. It's a tool that makes it really easy to end up running a command in the wrong environment and see weird behavior instead of a clear error message. I've seen variations on this scenario happen at least 3 times, for instance: 1) Somebody creates script that activates and runs django and commits it. 2) Junior runs script but the virtualenv doesn't get created for some reason. 3) The "warning virtualenv doesn't exist" message appears briefly and gets missed. 4) The junior gets "import error: cannot import django" or something. 5) They then start installing django in their system environment and... it sort of works. Except then they get another import error. And a whole bunch of python packages installed in their system environment. Yech. Moreover, I'm really not sure what was so wrong with just running ./venv/bin/python in the first place and never having to worry about what environment you're in.