3 ms·
I would not recommend make for python projects as make does not play nicely with virtualenvs and the environment variables that power them. You can make it work
by bragr 4y ago
I would not recommend make for python projects as make does not play nicely with virtualenvs and the environment variables that power them. You can make it work, but you'll be fighting it constantly.
- hprotagonist 4y ago“never activate venvs in a headless context” is sage advice and not just for make.
- kelseyfrog 4y agoAre you specifically talking about virtualenv or the concept of venvs in general? I've used make with conda, for example, for the last five years with no env issues at all, so some clarity or specific problem cases would help.
- kortex 4y agoWhat exactly are you doing that hits friction? You shouldn't be using "make" to "activate" your env - that should occur "outside" your makefile. It plays totally nice if you aren't trying to use make to set environmental state.
- cpburns2009 4y agoAn easy way to use virtual environments with Make is to create a wrapper script to activate the virtual environment and run a command in its context: # venv.sh venv="$1" shift . "$venv/bin/activate" "$@" Then in the Makefile I do: VENV := venv.sh ./venv install-reqs: ${VENV} pip -r requirements.txt
- bragr 4y agoThat works but the whole point of the article was to avoid creating extra scripts, and now you have the problem that you need to document the extra required environment setup before running make or you get opaque errors.
- rcarmo 4y agoHow so? I have a Makefile in all of my Python projects. Never had issues.
- bragr 4y agoPersonally it's the interactions between the life cycle management of the virtual environments and bulletproofing for use by all team members. For any non-trivial Python project, I end up with at least 2 virtual environments, one "normal" and one for installing unit tests/linting/other static checkers. If you're environments are already pull this project and goes to `make lint`, is the lint virtual environment extant, does it have all the required dependencies, and are those steps idempotent so as not to trigger a setup on every run. And then add on edge cases like, what if someone already had a virtual env active when you went to do the setup, what edge conditions does that introduce? Do you add something to your logic to detect extant virtual environments and deactivate them before trying other actions. All of these problems are solvable of course, but at what level of effort and for what benefit? And you pay all these costs every time you want to change something, especially if you've got to explain all the hacks to someone new, and you always run the risk that it works for you but not in a clean environment.