misohu
commented
1 year ago ROCKing poetry environment
By default poetry creates a virtual environment for every folder where poetry install is executed. In the case of this image there are two projects:
- one for
pmmlserverfolder - one for
kservefolder
The upstream Dockerfile decided to solve this problem by installing both of poetry's projects under a common virtual environment /prod_venv.
I tried to replicate the same approach in the ROCK by poetry install both of the projects in the BUILD stage and later copying the virtual environment to the STAGING stage. The problem with this approach is that by moving the venv folder from BUILD to STAGING sim links in the venv persist. These sim links are still pointing to Python interpreter from BUILD which uses a different path in STAGE.
After discussion with Cristovao and Samir we decided that best approach is to drop the usage of common virtual environment for this usecase. In the poetry config you can disable the creation of the virtual environments by running poetry config virtualenvs.create false. After setting this all the poetry librarries will be installed under site packages of the base python interpreter. Now we don't have to move the virtual environment, we just need to move the installed site packages.
cp -fr /usr/local/lib/python3.X/dist-packages/* $CRAFT_PART_INSTALL/usr/local/lib/python3.X/dist-packages/
Description
PMMLServer ROCK is part of a collectoin of KServe ROCKs. It needs to be created using ROCK building best practices. It should be based on Kserver Docker container, eg. https://github.com/kserve/kserve/blob/master/python/pmml.Dockerfile More information on PMMLServer can be found here This is OpenJDK based container.
More details on Kserve can be found here Charmed Kserver operators repository contains code that manages Kserve in Charmed Kubeflow deployments: https://github.com/canonical/kserve-operators