Ensure no missing pip dependencies in build_image.py

[ANogin]

One sentence summary of this PR (This should go in the CHANGELOG!)
This changes the make install/make develop step of the finish.Dockerfile to run with network disabled, which means that any missing dependencies that were not properly installed in base.Dockerfile result in a build failure and flagged.

Link to Related Issue(s)
Would enable detecting things like #419 would be detected by CI. This depends on #571 fixing #419 (until that is fixed, this change would break the build - will keep it in draft state until then).

Please describe the changes in your request.
See summary.

Anyone you think should look at this, specifically?
@whyitfor

[ANogin]

@whyitfor could we please land this one and use the new option in our CI? As I am working on #416 and #417 I am went to go back to this manually to make sure all the dependencies across ofrak components are consistent (only remembered to do it because I saw the docker build output for #417 and noticed it's uninstalling/reinstalling some packages in weird way in make develop) - and now discovering that even the main branch has incorrectly specified dependencies (will fill in separate PRs on those)?

[whyitfor]

@ANogin, can you complete the PR descripion for this?

[whyitfor]

I've reflected on this one a bit, and discussed with @rbs-jacob.

Let's make the following changes.

1. Remove the check-python-reqs argument from build-image.py
2. build-image.py should add an inspect target to the Makefile it generates that runs python3 -m pip check. This will enable users who want to check for this consistency to do so.
3. Does --network="none" work for all use cases? If so, let's make it default. If not, we should remove it.

[ANogin]

I've reflected on this one a bit, and discussed with @rbs-jacob.

Let's make the following changes.

1. Remove the check-python-reqs argument from build-image.py
2. build-image.py should add an inspect target to the Makefile it generates that runs python3 -m pip check. This will enable users who want to check for this consistency to do so.
3. Does --network="none" work for all use cases? If so, let's make it default. If not, we should remove it.

Done, should be good to go once #419 is fixed.

[whyitfor]

I don't understand why this change is needed.

#561 updated these targets to enable editable_mode=compat -- is this not the same issue?

cc @alchzh

[alchzh]

yes this change is no longer needed (the command line flag is preferred over the environment variable)

[ANogin]

No, with command line flag it insists on reaching out to pypi over network, but with the environment variable it does not.

[whyitfor]

I've looked into this a bit and reflected.

If I understand correctly,SETUPTOOLS_ENABLE_FEATURES results in using a pre-PEP 517 backend. editable_mode=compat uses a PEP660 backend that provides some backwards compatibility. Switching back to SETUPTOOLS_ENABLE_FEATURES does not make sense to me: is moving the repo in the wrong direction, away from PEP660.

It looks like there are ways to get pip to not reach out to the network (a combination of --no-index and --find-links) which we might want to eventually look into.

For now though, I'd like to prioritize getting the pip check functionality this MR adds in, without the --network="none" changes.