You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
With the recent CMake rework the majority of Python code was structured so the modules belong to its own packages. This allows for tight enclosing of the logic and it's implementation, distribution via PEP503 API and installation in arbitrary Python virtual environments. This all in theory should help the ease of development and deployment.
Problem is in how the Python packages are now represented in the Machinekit-HAL repository. Because the structure is not how one would presume normal Python project should look like. Instead CMake at configure stage creates the tree structure via multiple configure_file calls in the BUILD TREE. From these the wheel are build and these are then installed into the development virtual environment from where the code can be run as part of the Machinekit-HAL suite.
As you can probably determine from the description alone, this makes for terrible developer's experience. He has to change the code, rerun the CMake program so the changes are propagated to the BUILD TREE from BINARY TREE, then he has to build the specific Python target to get the wheel out of it and then he has to rebuild the whole development virtual environment. (Which can take alone 30 seconds.)
(One of reasons and the main one why this was done how it was done is to avoid polluting BINARY TREE with any files Python interpreter creates when it is run [or can create depending on settings], for example the Python bytecode, PyTest cache etc. All has to be run from BUILD TREE to contain it.)
A much better workflow would be to have same structure in BINARY TREE and in BUILD TREE, maybe - if this can work - have only symlinks in BUILD TREE so that the CMake does not need to be rerun at each change to the code and start using the developing mode (I think it is called a editable mode in pip) in the development virtual environment. While creating wheels/sdists only when installing and/or packaging.
The text was updated successfully, but these errors were encountered:
With the recent CMake rework the majority of Python code was structured so the modules belong to its own packages. This allows for tight enclosing of the logic and it's implementation, distribution via PEP503 API and installation in arbitrary Python virtual environments. This all in theory should help the ease of development and deployment.
Problem is in how the Python packages are now represented in the Machinekit-HAL repository. Because the structure is not how one would presume normal Python project should look like. Instead CMake at
configure
stage creates the tree structure via multipleconfigure_file
calls in the BUILD TREE. From these the wheel are build and these are then installed into the development virtual environment from where the code can be run as part of the Machinekit-HAL suite.As you can probably determine from the description alone, this makes for terrible developer's experience. He has to change the code, rerun the CMake program so the changes are propagated to the BUILD TREE from BINARY TREE, then he has to build the specific Python target to get the wheel out of it and then he has to rebuild the whole development virtual environment. (Which can take alone 30 seconds.)
(One of reasons and the main one why this was done how it was done is to avoid polluting BINARY TREE with any files Python interpreter creates when it is run [or can create depending on settings], for example the Python bytecode, PyTest cache etc. All has to be run from BUILD TREE to contain it.)
A much better workflow would be to have same structure in BINARY TREE and in BUILD TREE, maybe - if this can work - have only symlinks in BUILD TREE so that the CMake does not need to be rerun at each change to the code and start using the developing mode (I think it is called a
editable mode
in pip) in the development virtual environment. While creating wheels/sdists only when installing and/or packaging.The text was updated successfully, but these errors were encountered: