Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

bpo-43312: Functions returning default and preferred sysconfig schemes #24644

Merged
merged 6 commits into from
Apr 27, 2021

Conversation

uranusjr
Copy link
Contributor

@uranusjr uranusjr commented Feb 25, 2021

@github-actions
Copy link

This PR is stale because it has been open for 30 days with no activity.

@github-actions github-actions bot added the stale Stale PR or inactive for long period of time. label Mar 28, 2021
@uranusjr uranusjr force-pushed the sysconfig-preferred-scheme branch from acadc40 to a0d613f Compare March 29, 2021 20:17
@uranusjr uranusjr marked this pull request as ready for review March 29, 2021 21:36
@uranusjr
Copy link
Contributor Author

uranusjr commented Mar 29, 2021

Uh, how do I remove the stale label?

@github-actions github-actions bot removed the stale Stale PR or inactive for long period of time. label Mar 30, 2021
Copy link
Member

@pfmoore pfmoore left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I can't say whether the choices in _get_preferred_schemes are correct, but they seem reasonable. Unless there's anything we can check them against, I'd say we should go with them.

@@ -517,7 +542,7 @@ def get_path_names():
return _SCHEME_KEYS


def get_paths(scheme=_get_default_scheme(), vars=None, expand=True):
def get_paths(scheme=get_default_scheme(), vars=None, expand=True):
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we need to call this function every time? Wouldn't be better to call it just once and save it into a private global variable, and use that as the default value for all these methods?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That’s a separate issue already presented in the previous implementation. I’m not sure this is the best plac eto discuss the possible implications in e.g. multiprocessing settings (I don’t even have enough expertise to comment on it).

As it currently stands, the function is only called twice (get_paths and get_path) on import time, so the performance difference is pretty close to none anyway.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Agreed, let's keep the change to the minimal required.

Lib/sysconfig.py Outdated
@@ -731,7 +756,7 @@ def _main():
return
print('Platform: "%s"' % get_platform())
print('Python version: "%s"' % get_python_version())
print('Current installation scheme: "%s"' % _get_default_scheme())
print('Current installation scheme: "%s"' % get_default_scheme())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would be a good opportunity to migrate this to f-strings?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Probably, I’ll combine this to other needed changes, if there are any.

Copy link
Contributor

@hroncok hroncok left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I ❤️ it!

Several non-blocking questions attached.

However, I have a very strong suggestion: Please add tests.

Lib/sysconfig.py Outdated
Comment on lines 244 to 245
if scheme not in _INSTALL_SCHEMES:
raise KeyError(key)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Will the above lookup not raise already? Should this be done before calling _get_preferred_schemes?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The main intention is to guard against incorrect implementation, since _get_preferred_schemes() is expected to be modified by redistributors and implementers. Say an implementer makes a typo:

def _get_preferred_schemes():
    return {
        "prefix": "posix_prefix",
        "home": "posix_home",
        "user": "posix_uesr",  # Oops!
    }

And when the value is later used:

scheme = sysconfig.get_preferred_scheme("user")

...  # Much later...

paths = sysconfig.get_paths(scheme)

This check would catch that posix_uesr is not actually a valid scheme and error early, instead of later when the user actually tries to use the (invalid) scheme.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we raise a ValueError with a better message then? "Key '{}' returned scheme '{}' which is not valid on this platform" (or something more correct)

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I couldn’t think of a better message and implemented yours for now, any ideas are very welcomed. Ideally I want to point users to the implementer/redistributor instead of reporting the error to CPython, but that’s probably not really feasible.

Lib/sysconfig.py Outdated Show resolved Hide resolved
@uranusjr
Copy link
Contributor Author

I’ve changed get_default_scheme() to use get_preferred_scheme(), and a couple of simple tests for the new functions.

@frenzymadness
Copy link
Contributor

The implementation looks good to me.

@uranusjr
Copy link
Contributor Author

I’m wondering whether we should add documentation for the private _get_preferred_schemes() as well, to tell redistributors this is the function they’re advised to override/modify.

@encukou
Copy link
Member

encukou commented Apr 16, 2021

I’m wondering whether we should add documentation for the private _get_preferred_schemes() as well, to tell redistributors this is the function they’re advised to override/modify.

At least a docstring would be great, yes.

@uranusjr
Copy link
Contributor Author

uranusjr commented Apr 17, 2021

Documentation entry added 👍


Edit: Plus converting %-formatting to f-strings.

@hroncok
Copy link
Contributor

hroncok commented Apr 19, 2021

Curiosity question: Should distutils use this?

@uranusjr
Copy link
Contributor Author

Ideally yes, but distutils’s implementation around this is structured very differently, and tangled with a lot of things inside distutils.command.install, I’m not sure if it’s really worthwhile (or even doable without risking behavioural changes) 😞

Copy link
Member

@zooba zooba left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would like to see that error message improved, but the rest seems fine to me. I'm just taking on trust that it's sufficient for distros to override what they need, because I don't know that side of it well enough.

Lib/sysconfig.py Outdated
Comment on lines 244 to 245
if scheme not in _INSTALL_SCHEMES:
raise KeyError(key)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can we raise a ValueError with a better message then? "Key '{}' returned scheme '{}' which is not valid on this platform" (or something more correct)

@uranusjr
Copy link
Contributor Author

Another nudge 🙂

@pfmoore
Copy link
Member

pfmoore commented Apr 27, 2021

I believe all comments have been addressed, and I see no remaining concerns raised and general approval of the change, so I'm going to merge this based on my approval above.

@pfmoore pfmoore merged commit d925133 into python:master Apr 27, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

9 participants