Creating a Makefile for virtual development environments

[bayesflows]

Hello,

Would you be interested in me doing a PR with a Makefile file that automatically creates a virtual Python development environment with the right libraries ?

This allows the user to have all the necessary libraries and versions simply by running the documented make init command, and to run locally all tests of the project with make test command.

Moreover, for developers, creating a virtual development environment means that they don't have to install the necessary Python libraries on their Python system (because they install them in their venv). This ensures that there are no conflicts between libraries installed for different code repositories.

[kennethshsu]

Hi @bayesflows, I am not super familiar in this area, since I always just figure out what I need to make it work...

But my initial reaction is that we don't expect ordinary end users to setup environments as they are not developers. And, if they do want to make changes to the code, can't this be done with uv?

[bayesflows]

Hi @kennethshsu, the advantage of creating a virtual environment is that prevents users from encountering Python dependency issues (missing dependencies or conflicts between required versions), which means you will receive fewer support requests regarding the use of the repository.

Once the makefile has been created, users will simply need to run the make init command at the root of the repository, then source venv/bin/activate on Linux or source venv/scripts/activate on Windows (both commands will of course be documented), and they will then be sure to avoid any Python library conflicts, and without assistance.

[jbogaardt]

This sounds like an abstraction layer over uv and pytest and jupyterbook. The questions I have are:

1. Is the complexity underlying our tooling sufficient to warrant another layer?
2. Would it be an optional or mandatory standard imposed on contributors?

[henrydingliu]

Assuming the makefile file is package agnostic, maybe there's a spot elsewhere in the cas repository that it may be a better fit under? e.g. a place that covers basics of python development

[kennethshsu]

@bayesflows does this not do it?

[bayesflows]

Hi @jbogaardt, @kennethshsu and @henrydingliu ,

You're right. After reviewing the current setup, uv already handles most of the complexity elegantly. The 3-command workflow (uv sync, uv run pytest, make html in docs/) is simple enough that a root Makefile would add abstraction without significant value today.

That said, I noticed the project doesn't currently have linting/formatting enforcement (ruff, black), pre-commit hooks, or automated release scripts. If these were added in the future, a Makefile or task runner could help centralize those workflows.

For now, I agree it's not necessary. Maybe worth revisiting if the dev workflow grows more complex. You can therefore close the issue if you want to.

[kennethshsu]

@bayesflows glad that you agree that the current set up is good enough.

We currently don't have a standardized/agreed linter. I personally use black, but many use something else. This could be a good topic to discuss with the group I think...

Yes, we should definitely visit these workflows from time to time, perhaps for the v1.0 release?!