Using `venv` as a proper dependency

[Poddster]

venv is a .PHONY target and rules that depend on it will be executed every time make is run. This behavior is sensible as default because most Python projects use Makefiles for running development chores, not for artifact building. In cases where that is not desirable use order-only prerequisite syntax:

For the majority of my use, venv being phony is fine, as I can set it as an order-only dependency.

But I have a make rule that invokes pyinstaller, and so I want my output artefacts to be rebuilt if venv changes. What's the best way to do this? For now I've just gone for $(VENV)/$(MARKER), but is that the best solution? (Especially as it means I have to include Makefile.venv near the top)

[Poddster]

Actually, it looks like this is a bit of a moot point, as venv doesn't get "rebuilt" if there are any external changes.

i.e. if i do:

$ make venv
....
$ ./venv/Scripts/activate
$ pip install whatever
....
$ make venv
make: Nothing to be done for 'venv'.
(.venv)

So therefore if Makefile.venv exists then the only way to manage .venv is via the requirements file, make clean-venv and make clean?

[sio]

I want my output artefacts to be rebuilt if venv changes. What's the best way to do this? For now I've just gone for $(VENV)/$(MARKER), but is that the best solution?

I agree, adding a dependency on $(VENV)/$(MARKER) is the best solution here.

There is nothing bad in placing include directive closer to the top of your Makefile. README recommends adding it to the bottom to avoid confusing newbies who may be surprised by Makefile.venv overtaking the default goal if placed before any other recipes. You have clearly wandered into "advanced user" category already, so some .DEFAULT_GOAL trickery shouldn't scare you (if need arises).

venv doesn't get "rebuilt" if there are any external changes

Yes, of course it doesn't. I don't see any way for Makefile.venv to know that someone else has modified venv. Directory dependencies are really imprecise in GNU Make.

So therefore if Makefile.venv exists then the only way to manage .venv is via the requirements file, make clean-venv and make clean?

No one forbids you from modifying venv manually, but that's a sure way to create some confusion.

I tend to think of Python virtual environments as ephemeral entities, some sort of necessary evil required for Python to work - not as of valuable artifacts. Removing a misbehaving venv is a relatively cheap action, and even though I rarely need it I never try to avoid or postpone it when required.

Could you explain why you want your artifacts to depend on venv itself instead of whatever dependency that triggers venv modification?

[sio]

I'm closing this issue because the discussion seems to have dried out. Feel free to reopen if you have something to add.