fix(bzlmod): set the default_version to the python_version flag

[aignas]

With this change we set the default value of --python_version when
the python.toolchain is used in bzlmod and we generate the
appropriate config settings based on the registered toolchains and
given overrides by the root module.

This means that we expect the --python_version to be always set to
a non-empty value under bzlmod and we can cleanup code which was
handling //conditions:default case. This also means that we can
in theory drop the requirement for python_version in pip.parse
and just setup dependencies for all packages that we find in the
requirements.txt file and move on. This is left as future work
by myself or anyone willing to contribute. We can also start reusing
the same whl_library instance for multi-platform packages because
the python version flag is always set - this will simplify the layout
and makes the feature non-experimental anymore under bzlmod.

Summary:

• Add @pythons_hub to the WORKSPACE with dummy data to make
  pythons_hub work.
• Add MINOR_MAPPING and PYTHON_VERSIONS to pythons_hub to
  generate the config settings.
• Remove handling of the default version in pypi code under bzlmod.

Work towards #2081, #260, #1708

[aignas]

If we wanted, we could do extra plumbing within the pythons_hub and pass the correct values for minor_mapping and python_versions from the //python:versions.bzl, but given that WORKSPACE is on the way out and this is temporary, I thought it would be best to leave it like this.

[aignas]

Suggested change

	python_versions = ["3.7", "3.8", "3.9", "3.10"],
	# NOTE: We don't have any `3.7` in `//python:versions.bzl` and
	# this value has been selected on purpose to test what happens if the value
	# is unknown to rules_python - i.e. we should still be able to work.
	python_versions = ["3.7", "3.8", "3.9", "3.10"],

[rickeylev]

This also means that we can in theory drop the requirement for python_version in pip.parse

Oh? How? Aren't we still stuck with the case where the same python version interpreter has to go find and download something? sdists?

I think I see what you mean for a pure-wheel build. Well, maybe. When requirements.in is resolved by e.g. compile_pip_requirements to a particular python-specific requirements.txt, the python version has, effectively, been decided. But -- I don't recall requirements.txt storing the python version? So how do we know that foo == 1.2.3 # hash blabla means el.g. foo-1.2.3-cpython-313.tar.gz (as opposed to foo-1.2.3-cpython-310.tar.gz) ?

[rickeylev]

Hm, maybe we should expose python_version_major_minor as a public setting. Otherwise, users don't have a good way to perform e.g. select({"3.10": ..., "3.11": ...}), which is the most common type of selection on python version.

Don't have to address in this PR though.

[rickeylev]

CI's error is about running it under Bazel 6 -- I think it's trying to say pythons_hub isn't defined. Though, the (Mac, pystar, workspace) job is also failing and that is using Bazel 7. Looks like something to do with workspace builds.

[rickeylev]

Ok, think I found the problem (wrong load in a test file). Pushed a fix. CI is acting weird right now, though. Maybe it'll be in a better mood when you log on; I suggest pushing a no-op change and having it start over.

[aignas]

This also means that we can in theory drop the requirement for python_version in pip.parse

Oh? How? Aren't we still stuck with the case where the same python version interpreter has to go find and download something? sdists?

I think I see what you mean for a pure-wheel build. Well, maybe. When requirements.in is resolved by e.g. compile_pip_requirements to a particular python-specific requirements.txt, the python version has, effectively, been decided. But -- I don't recall requirements.txt storing the python version? So how do we know that foo == 1.2.3 # hash blabla means el.g. foo-1.2.3-cpython-313.tar.gz (as opposed to foo-1.2.3-cpython-310.tar.gz) ?

The idea is that we can just always define whl_library instances for all of the dists we find in a requirements file and we don't need to know the version of the python interpreter that we are getting. Sometimes the wheels could be missing though, but in the issue linked to the PR (#1708), the same requirements.txt is used for each python_version, so sometimes requirements.txt can be multi-version compatible.

This is only true for wheels though. For sdists we would need to iterate through registered python toolchain repository minor versions and add a whl_library instance per python version for each sdist we find. This is until we can build sdist to whl in a build context.