Add Python packages to docker base image

[r0qs]

• [x] Add parsec and tabulate python packages to base image, as noted here. Maybe we should also include the requests package.
• [ ] Choose the default Python version in the base image to avoid incompatibility with default python versions on Windows and Linux machines. See comments: https://github.com/ethereum/solidity/pull/14839

[cameel]

Maybe we should also include the https://github.com/ethereum/solidity/pull/14839#discussion_r1486084352 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.

[r0qs]

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

[cameel]

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.

[nikola-matic]

Add parsec and tabulate python packages to base image, as noted here. Maybe we should also include the https://github.com/ethereum/solidity/pull/14839#discussion_r1486084352 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.

[cameel]

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.

[nikola-matic]

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 https://github.com/ethereum/solidity/pull/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.

[github-actions[bot]]

This issue has been marked as stale due to inactivity for the last 90 days. It will be automatically closed in 7 days.

[github-actions[bot]]

Hi everyone! This issue has been automatically closed due to inactivity. If you think this issue is still relevant in the latest Solidity version and you have something to contribute, feel free to reopen. However, unless the issue is a concrete proposal that can be implemented, we recommend starting a language discussion on the forum instead.