Support multiple venvs in Makefile

[laenan8466]

Reference: pawamoy/pdm-multirun#10

Adding the handling of PDM_MULTIRUN_USE_VENVS in script/setup.ph and giving the option for the Makefile.

• Changing setup.ph to check for the environment variable and if set to 1 creating named venvs (e.g. 3.11, exactly as the version specifier. One could change this if another behavoir is preferred, no strong opinion here)
• Adding a comment to the Makefile, that can be uncommented.
• Updating docs (couldn't check docs, mkdocs callouts didn't worked for me.

Not sure on the documentation, not too experienced there. Please check and change to your likeing.

[laenan8466]

Having some new issues with the 'default' use. Investigating.

[laenan8466]

Ok, found the culprit in my code/installation.
Tests were not finishing in my installation, bc. of my stupidity (multiple test dependencies like duty, safety & griffe were missing in the pdm I created for that.

• Tests are successful, can you confirm that?
• Tested manually with uncommented line in Makefile as well (didn't manage to automate tests for that - improvement for the future?).

On the other hand, CI is failing due to unkonwn reasons and I do not want to investigate. 🤐 But saw your last commit was failing as well, so I guess s.th. unrelated?

[pawamoy]

Thanks!

So, I tested locally, and it does seem to require setting python.use_venv = true in the local config, because otherwise it says Using __pypackages__ because non-venv Python is used.. Not sure if this is a bug in PDM, or an oversight in PDM Multirun.

That got me thinking. Maybe we could have an automated mode in the setup script: if the user config says use_venv: true, then export PDM_MULTIRUN_USE_VENVS=1. If not, don't change anything. This way individual contributors can choose between venvs and pypackages by configuring PDM directly :D

I'll push a commit to your branch with my changes so you can see and test 🙂

[laenan8466]

Hi!
This is great! That solution is far better than mine! Guess this was not showing in my installation, as I have the option set to use_venv: True and yeah. Fully support that idea.

There is an odd thing indeed:
When running the test script now with my previous setup (additional venv in copier-pdm directory to install testing dependencies (ruff, safety, ...)) it is defaulting to this outer venv during test. This is from a pdm multirun call within the ./tests/tmp/ folder. I see no reason, why this behavior should have changed from your changes. So I think it is an fail/issue on my local machine.

• How do you solve this in your local installation?
• Do you have these packages in your local python/pipx installation/inject to duty pipx?

mypy --config-file config/mypy.ini src tests duties.py scripts
  scripts/insiders.py:18: error: Library stubs not installed for "yaml"  [import-untyped]
  scripts/insiders.py:18: note: Hint: "python3 -m pip install types-PyYAML"
  scripts/insiders.py:18: note: (or run "mypy --install-types" to install all missing stub packages)
  scripts/insiders.py:18: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
  Found 1 error in 1 file (checked 11 source files)

This could be a result from that issue, getting this new typing error now.

From my point of view we could continue with this version.

[pawamoy]

Should be better now. Previously, only the setup action would handle both venvs/pypackages. Now all actions do.

Windows failures are unrelated.

[pawamoy]

OK, LGTM, merging, thanks a lot for your contribution!

[pawamoy]

In the future it would probably be better to implement this in PDM Multirun directly 🙂