Move our build system to `poetry`

[alexlib]

We first built with setuptools and used requirements.txt to keep dependicies. Then we added Github actions and then followed some recommendation to use pyproject.toml as the future method of consistent builds.

Describe the solution you'd like
Use poetry https://python-poetry.org/docs/basic-usage/ and Github actions for consistent testing, build, doc build, PyPi and ReadTheDocs uploads.

[alexlib]

Possibly follow https://cookiecutter-hypermodern-python.readthedocs.io/en/2020.6.15/quickstart.html
or manually using
https://hackersandslackers.com/python-poetry-package-manager/

[ErichZimmer]

@alexlib
As we incorporate poetry, should we turn OpenPIV-Python into a namespace package like this?

[alexlib]

sorry @ErichZimmer i didn't understand what you suggested.

[ErichZimmer]

Instead of having .py files containing all the relevant functions, I think we should create submodules (folders inside of the main openpiv package containing the relevant code) so the code can be broken down into different files. For instance, let's take the windef.py file and make a folder with an _init.py_ in it. Then, we can split windef.py into something like _windef.py (contains the windef class/script), _deformation.py (contains functions related to deformation), and _piv_eval (contains the first pass and multipass deformation PIV code). So a tree structure along the lines as:

openpiv/
    __init__.py
    pyprocess/
        __init__.py
        _correlators.py
        _corr_stats.py
        _grid_generation.py
    windef/
        __init__.py
        _deformation.py
        _piv_eval.py
        _windef.py
  

The code in each submodule is imported by the init.py so it essentially acts like one large python source file.

A better example (one that I tried to link but misplaced the location) can be seen with the OpenPIV-Python-cxx package where i decided to make it a namespace package. Here is the link to the windef submodule of that package.
https://github.com/ErichZimmer/OpenPIV-Python-cxx/tree/4-pocketfft-support-and-others/lib/windef

Scipy, skimage, and I think numpy are namespace packages too. Here is the link for the basic idea of namespace packages from Python.

I simply think namespace packages have the advantage of splitting large files in a way that code is more readable and maintainable, but it is not strictly necessary as it is basically an aesthetic thing.

[alexlib]

sounds good as long as our GUI and other users wont need to do a lot of recoding

…

On Wed, 21 Jun 2023 at 7:29 Erich Zimmer ***@***.***> wrote: Instead of having .py files containing all the relevant functions, I think we should create submodules (folders inside of the main openpiv package containing the relevant code) so the code can be broken down into different files. For instance, let's take the windef.py file and make a folder with an _*init.py_* in it. Then, we can split windef.py into something like _windef.py (contains the windef class/script), _deformation.py (contains functions related to deformation), and _piv_eval (contains the first pass and multipass deformation PIV code). So a tree structure along the lines as: openpiv/ __init__.py pyprocess/ __init__.py _correlators.py _corr_stats.py _grid_generation.py windef/ __init__.py _deformation.py _piv_eval.py _windef.py The code in each submodule is imported by the *init*.py so it essentially acts like one large python source file. A better example (one that I tried to link but misplaced the location) can be seen with the OpenPIV-Python-cxx package where i decided to make it a namespace package. Here is the link to the windef submodule of that package. https://github.com/ErichZimmer/OpenPIV-Python-cxx/tree/4-pocketfft-support-and-others/lib/windef Scipy, skimage, and I think numpy are namespace packages too. Here <https://packaging.python.org/en/latest/guides/packaging-namespace-packages/> is the link for the basic idea of namespace packages from Python. I simply think namespace packages have the advantage of splitting large files in a way that code is more readable and maintainable, but it is not strictly necessary as it is basically an aesthetic thing. — Reply to this email directly, view it on GitHub <#278 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAFWMZTHKSZAOF6GWHVHQC3XMMALPANCNFSM6AAAAAASLLB4FA> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[yuriishizawa]

@alexlib I would like to help in this task. Do you still interested in move the build to poetry?

[alexlib]

@alexlib I would like to help in this task. Do you still interested in move the build to poetry?

Yes definitely- please your help