Project-based venv

[asmodehn]

This depends on #89

Adds a target to the makefile, to deploy to a project based venv. This allows to gather dependencies into a requirements.txt file.

Also installing in a clean virtual env from the wheel revealed missing dependencies in setup.py

Possible future improvements:

• separate system management commands, and python project development commands, currently both conflated in same makefile (but with potentially very different impact on the user's machine).
• have a separate version file, so we don't need to import the whole opengeode package (with potentially missing dependencies) when grabbing the version.

[asmodehn]

I recently rebased this onto the recent makefile_improvements. Things are working fine. I can make develop to work from a project-based venv. I can also build a wheel and install it via pip:

$ pip install dist/opengeode-4.0.2-py3-none-any.whl 
Processing ./dist/opengeode-4.0.2-py3-none-any.whl
Requirement already satisfied: pygraphviz in /home/alexv/.local/lib/python3.10/site-packages (from opengeode==4.0.2) (1.10)
Requirement already satisfied: pyside6 in /home/alexv/.local/lib/python3.10/site-packages (from opengeode==4.0.2) (6.4.2)
Requirement already satisfied: shiboken6==6.4.2 in /home/alexv/.local/lib/python3.10/site-packages (from pyside6->opengeode==4.0.2) (6.4.2)
Requirement already satisfied: PySide6-Addons==6.4.2 in /home/alexv/.local/lib/python3.10/site-packages (from pyside6->opengeode==4.0.2) (6.4.2)
Requirement already satisfied: PySide6-Essentials==6.4.2 in /home/alexv/.local/lib/python3.10/site-packages (from pyside6->opengeode==4.0.2) (6.4.2)
Installing collected packages: opengeode
  Attempting uninstall: opengeode
    Found existing installation: opengeode 4.0.2
    Uninstalling opengeode-4.0.2:
      Successfully uninstalled opengeode-4.0.2
Successfully installed opengeode-4.0.2

One thing I don't really like is the fact that I have to activate the virtual env from the makefile at every line there (make will create a new shell process for each line, to mitigate side-effects damage, and therefore we loose the virtualenv).

Which is why I would like to move the "non-obvious" steps outside the makefile if possible (in a later PR):

• dealing with antlr3_python3_runtime as a proper pip dependency, somehow...
• doing pyside6-rcc opengeode.qrc -o opengeode/icons.py manually, or automate it in a different way, and put icons.py in repo ?... Let me know if you have any idea about those, or if you prefer the PR as is now.

[maxime-esa]

One thing I don't really like is the fact that I have to activate the virtual env from the makefile at every line there (make will create a new shell process for each line, to mitigate side-effects damage, and therefore we loose the virtualenv).

Why don't you use && between each command to avoid this ?

Also I am not sure to understand - the install rule depends on develop. Does it mean that it will be installed twice - first in the venv then on the system ?

Which is why I would like to move the "non-obvious" steps outside the makefile if possible (in a later PR): * dealing with antlr3_python3_runtime as a proper pip dependency, somehow...

Yes the solution would be to upload this runtime on PyPi, making it available properly to everyone

* doing `pyside6-rcc opengeode.qrc -o opengeode/icons.py` manually, or automate it in a different way, and put icons.py in repo ?...

In general I don't want to put generated code on the repo

[asmodehn]

One thing I don't really like is the fact that I have to activate the virtual env from the makefile at every line there (make will create a new shell process for each line, to mitigate side-effects damage, and therefore we loose the virtualenv).

Why don't you use && between each command to avoid this ?

Sure, I could do this, but it is perhaps less clear which command will embed which shell (and how errors will be back-propagated), and anyway I see it as a hint that doing so many steps in the Makefile is not the way to go about it...

Also I am not sure to understand - the install rule depends on develop. Does it mean that it will be installed twice - first in the venv then on the system ?

Correct. Note I only install it on the venv to be able to generate the resources with pyside6-rcc, so that the file is present when installing afterwards...

Which is why I would like to move the "non-obvious" steps outside the makefile if possible (in a later PR):

• dealing with antlr3_python3_runtime as a proper pip dependency, somehow...

Yes the solution would be to upload this runtime on PyPi, making it available properly to everyone

For later reference, there seems to be a way to bring it along from opengeode setup.py directly, called direct references : https://peps.python.org/pep-0440/#direct-references This would allow to install it when installing opengeode, without having to make it a pip package by itself. Disclaimer, I havent tried that feature yet.

* doing `pyside6-rcc opengeode.qrc -o opengeode/icons.py` manually, or automate it in a different way, and put icons.py in repo ?...

In general I don't want to put generated code on the repo

Here is an interesting option: do it in the setup.py : https://gist.github.com/ivanalejandro0/6758741 This way we could hook it to existing commands. Ref: https://setuptools.pypa.io/en/latest/userguide/extension.html#customizing-commands or maybe even via a build sub-command since we just deterministically build a file here: https://setuptools.pypa.io/en/latest/userguide/extension.html#supporting-sdists-and-editable-installs-in-build-sub-commands

[maxime-esa]

• dealing with antlr3_python3_runtime as a proper pip dependency, somehow...

Yes the solution would be to upload this runtime on PyPi, making it available properly to everyone

For later reference, there seems to be a way to bring it along from opengeode setup.py directly, called direct references : https://peps.python.org/pep-0440/#direct-references This would allow to install it when installing opengeode, without having to make it a pip package by itself. Disclaimer, I havent tried that feature yet.

What about python3 -m pip install --user https://download.tuxfamily.org/taste/antlr3_python3_runtime_3.4.tar.bz2 ? That seems to work as well.