Add Python packages to docker base image about solidity HOT 6 OPEN

Maybe we should also include the #14839 (comment) package.

Yeah, if it's not already there. Our Python tests require it and they work so I assume it's there.

Choose the default Python version in the base image

An important part of that is to then switch from python3 to python where needed and remove the hard-coded Python version (3.12) from the Windows Python job.

from solidity.

Yeah, if it's not already there. Our Python tests require it and they work so I assume it's there.

They are not, most of the python packages are installed per-job/step basis. For example: https://github.com/ethereum/solidity/blob/develop/.circleci/config.yml#L914 and https://github.com/ethereum/solidity/blob/develop/.circleci/config.yml#L1441

from solidity.

Interesting. t_ubu_pyscripts does not install it even though unit tests require it (at least they did when I ran them locally in a clean virtualenv). It's actually weird because it randomly failed in my PR a few times due to missing requests but it went away after some reruns.

By the way, we should add those packages listed for chk_pylint to the base image too. The less we have to install at runtime in CI, the better, unless something has to be really bleeding edge like Foundry.

from solidity.

Add parsec and tabulate python packages to base image, as noted here. Maybe we should also include the #14839 (comment) package.

Should we not just have a requirements.txt file and install the same dependencies everywhere. At the moment, requests is not present in the Windows images, but is in all of the other ones.

from solidity.

Maybe. The issue is that we require quite a few packages, some of which could be quite heavy or exotic but each script individually needs only one or two of them.

Another complication is that I can easily see us adding something to the requirements.txt but forgetting to update the images so maybe the image would be better place to list them.

But overall I'm not against the idea if we can solve these problems. Having a common base that we can rely on being always present would also be pretty convenient. I'm usually reluctant to add dependencies when writing one-off Python scripts because ensuring that I have them everywhere I need it is cumbersome.

from solidity.

Maybe. The issue is that we require quite a few packages, some of which could be quite heavy or exotic but each script individually needs only one or two of them.

Another complication is that I can easily see us adding something to the requirements.txt but forgetting to update the images so maybe the image would be better place to list them.

But overall I'm not against the idea if we can solve these problems. Having a common base that we can rely on being always present would also be pretty convenient. I'm usually reluctant to add dependencies when writing one-off Python scripts because ensuring that I have them everywhere I need it is cumbersome.

By the way, your PR that was failing previously (3.11) is now passing (3.12). I've opened a draft PR #14873 to force install python 3.12 via chocolatey, and provide a symlink from that. Not exactly the prettiest approach, but should provide a stable fix for the time being.

from solidity.