Run pre-commit-vauxoo in python 3.8 #203
Comments
|
If we use this way should we create a custom image for each python version instead of using the current one Is fine this for you? |
Why? |
|
pylint raises different errors based on python version e.g. CurrentThreading vs current_threading |
Closes Vauxoo#203. Running pre-commit-vauxoo in versions other than python3.8 can generate inconsistencies between local dev containers and the CI. The new build script for Deployv takes this into account and installls pre-commit-vauxoo in a python3.8 interpreter. This is useful for dev containers working on older odoo versions, in which the default interpreter is not python3.8. If the default interpreter is already python3.8, pre-commit-vauxoo is installed directly in it.
Closes Vauxoo#203. pre-commit-vauxoo requires Python 3.7 or greater to run. Some containers in Odoo 12 and below are using Python 3.6, as a workaround, if the Python version detected is not suitable, Python 3.8 will be installed and used for running pre-commit-vauxoo.
Closes Vauxoo#203. pre-commit-vauxoo requires Python 3.7 or greater to run. Some containers in Odoo 12 and below are using Python 3.6, as a workaround, if the Python version detected is not suitable, Python 3.8 will be installed and used for running pre-commit-vauxoo.
|
@moylop260 Sorry, github wasn't sending me the notifications. You mean a container per python version only for the pre-commit job? EDIT: If so, no problem, there is not much to change in that case. |
Yes, we are still maturing the idea Otherwise, Could we use the quay.io customer image but installing pre-commit-vauxoo Using this way we will use the exact python version than the project needs But not sure yet since that it could require pre-install the packages in the production image (risky but faster) or install on-the-fly the packages (slow but safe) Or install on-the-fly the packages using gitlab-caches We even need to make the POCs |
|
@moylop260 I think it is better to have an image per python version. We could use the customer image, but it will always be behind, or we will need a fixed image in the job which in turn will be like having a custom python image. Or install pre-commit-vauxoo in every job, so we can use the actual image. But we already have an image that supports multiple python versions here. It is used to test DeployV we could use that as a base (maybe another branch?) and use the python_version variable to instantiate the proper environment. In this way, we only would have a single image that can work for all customers with little extra work. What do you think? |
|
Using a image with different py versions could work |
Running
pre-commit-vauxooin different python versions may generate inconsistencies with the CI, which uses python3.8 (at least in most cases). Therefore t2d containers should runpre-commit-vauxooinpython3.8, instead of using the container's default python version.The text was updated successfully, but these errors were encountered: