[build] pin setuptools to avoid installation failures

[Shastick]

Since python:3.12.5-slim, setuptools is not pre-installed anymore, causing our builds to fail when using this (or later) images.

This PR follows the second option outlined in this comment to allow pinning setuptools using the --allow-unsafe flag, as suggested as a fix by pip-tools:

# WARNING: The following packages were not pinned, but pip requires them to be
# pinned when the requirements file includes hashes and the requirement is not
# satisfied by a package already installed. Consider using the --allow-unsafe flag.
# setuptools

This is an alternative to #779 to fix #768

[barroco]

Could you please add a comment to justify the usage of --allow-unsafe / a reference to the issue ?

[Shastick]

Could you please add a comment to justify the usage of --allow-unsafe / a reference to the issue ?

Updated the comment in the Makefile with a reference to the issue

[Shastick]

Added comments/references in two more places

[barroco]

I don't think the justification is solid enough to move forward. We need to understand the problem reported in #771 because, as discussed during the Contributors Weekly call, this has an impact on the baseline of tests which may have a significant impact for current real world deployments.

[BenjaminPelletier]

I think we should stay with more pinning rather than less since sometimes our users will need a particular commit to work on an ongoing basis, and more pinning makes that more likely.

[BenjaminPelletier]

Is there a reference as to why it's unsafe? Is it because setuptools is used to install packages, so we're basically trying to upgrade the thing that upgrades things? If so, shouldn't we explicitly update setuptools to a specific pinned version individually before then (separately) using it to install/upgrade all other dependencies? If that were the case, it seems like that strategy would achieve both pinning and safety.

[Shastick]

Options to move forward:

1. If possible, Install pip via a separate step in the Dockerfile, continue not using --allow-unsafe as we currently do on master. Pin the dependency of setuptools to a well-defined version to help with [ci] increase build reproducibility  #778.
2. Add setuptools to requirements.in and add the --allow-unsafe flag when building requirements.txt (what this PR currently proposes).

About --allow-unsafe :

Here is an issue with some guesses as to why some packages are defined as unsafe.

The TL/DR:

There are only three packages that are deemed 'unsafe': UNSAFE_PACKAGES = {"setuptools", "distribute", "pip"}. This list has not changed since 2017.

The only effect of --allow-unsafe seems to be to allow pinning any of these three packages.

The rationale behind avoiding the unsafe packages is that these are often installed in environments using a package manager and not via pip, sometimes causing problems when they are both present in a requirements file and already installed with a conflicting version.

Forward

Given that the interuss/monitoring project has full control of the build process, both options above are equally suitable: assuming both work, we may easily switch between any of the two if it should become necessary.

I we can get it to work, I'd suggest going with option 1. above (install and manage setuptools outside of the requirements.in file) to stay close to what the pip-tools authors recommend and avoid frightening users with a poorly documented --allow-unsafe option.

Failing that, option 2. has no drawbacks that I am aware off and can be used as well.

[Shastick]

Closed in favor of #779