Open Flamefire opened 2 months ago
@Flamefire Can you look into fixing the merge conflicts?
I'm keen on getting this merged soon, but there's a lot of code shuffling going on here that makes the review a bit tough...
Ok, the merge conflict mostly originated from the addition of a max-Python version. I added that to the moved code.
I split up the change into one commit that should only be a refactoring without any effective changes, then the actual change(s)
While doing the refactoring I noticed some weirdness with specifying the required Python version in ECs using the system Python dependency:
req_py_majver
is set, the minor version will be set to the minor version of the used python which doesn't make senseI fixed both in separate commits to avoid having to test this code again.
I can split this into 3 PRs though if preferred (refactoring, pip-check, pyver fixes)
I copied the refactoring to https://github.com/easybuilders/easybuild-easyblocks/pull/3475 for easier review
Both tested with a random selection of recent-ish PythonBundle and PythonPackage ECs
Test report by @Flamefire
Build succeeded for 13 out of 13 (13 easyconfigs in total) i7139 - Linux Rocky Linux 8.9 (Green Obsidian), x86_64, AMD EPYC 7702 64-Core Processor, Python 3.8.17 See https://gist.github.com/Flamefire/a4a6e8292ac9c977a15360f7828db932 for a full test report.
This needs rebasing on #3475 now
This needs rebasing on #3475 now
Done and split the pyver fix commit into #3478
(created using
eb --new-pr
)We have 2 checks in PythonPackage:
pip check
pip list
-> Check for "0.0.0" versionsIn
PythonBundle
those are run for every extension after the build of the whole EC even though running it once is enough because the result will always be the same.This PR uses the following logic:
sanity_pip_check
should be set at the top ofPythonBundle
and not for the individual extensions. Currently if any extension has it enabled the check will be run so it does not make sense to disable/enable it for individual extensions.PythonBundle
passes its value for this to every extension as a default so a deprecation is added in case it gets changed in an extension.Similar reasoning applies to
unversioned_packages
: Only a single value for the whole bundle is useful and hence should be set at the top. For kind of backwards compatibility during the deprecation an union of all those values is used in the check.PythonPackage does no longer do the pip checks if it is an extension and the parent EC (e.g.
PythonBundle
) has a value forsanity_pip_check
set.PythonBundle
does the pip check if itself or any extension has requested it issuing a deprecation if something differs.Refactoring
To make this possible some refactoring was required.
This makes the diff look large although it is mostly moved code. Explanation follows to help navigate the changes
run_pip_check
is moved out ofsanity_check_step
ofPythonPackage
such that it can be used byPythonBundle
det_installed_python_packages
out of the class too, the originalPythonPackage.get_installed_python_packages
needs to stay for backwards compatibility which prevents giving the same name to the free function. Maybe in EB 5 we can remove it and useget_installed_python_packages
for the global method?det_
-prefix is chosen similar todet_py_libdirs
PythonBundle.sanity_check_step
now requirespython_cmd
to be available which was only set in theprepare_step
that is skipped in--sanity-check-only
--> Factor outprepare_python
fromprepare_step
similar toPythonPackage
python
command to use although I see no reason for that. I factored outfind_python_cmd
fromPythonPackage.prepare_python
and call it fromPythonBundle
. I left the check for a loadedPython
module inPythonBundle
as I don't know the reason for that check. IMO it should either be in both or neitherFixes #3418
I overwrite
_sanity_check_step_extensions
now for this. This also ensures that the extensions are initialized. Related PR: https://github.com/easybuilders/easybuild-framework/pull/4620