-
Notifications
You must be signed in to change notification settings - Fork 20
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
Prefer site-packages paths with Python version #35
Prefer site-packages paths with Python version #35
Conversation
On Linux, you get python3.6/site-packages or python3/site-packages. This helps to ambiguate these paths for different versions of Python. On Windows, it is typically \usr\Lib\site-packages, so we cannot rely on the version being present.
Is the version a concern? The c-extension modules are version-specific or abi3 which should be loaded by any version, right? |
Should there be a check that there is not more than one valid path? |
@mattip The version is a concern if I build numpy for py311 and py310 side-by-side. What do you think is the logic for only one valid path? Perhaps filter the list using |
Why? What is the concern? The python files are identical, and the c-extensions have different names. I understand meson will create two directories on linux: |
If that doesn't exist, error "something is wrong"
I would prefer a clear error when testing starts and not a "cannot import" error later on |
But do we know what the path will look like on different platforms? Windows has no version info, Python seems to add major and sometimes minor version, not sure about MacOS? |
I think I would prefer this, does it make sense?:
|
I recommend copying the logic from SciPy's I am seeing this problem locally as well now for some reason, where before it used to work. Not sure what changed, maybe Python version or some such thing. |
That logic relies on
Directly searching for the path seems like a simpler alternative, if we can make it work?
Perhaps you're on the previous version still? On |
That looks correct, except that the more specific check (3.10) needs to come before the less specific check (3). |
@mattip How about this version? The exact heuristics that need to be replicated are the ones from mesonpy, I suppose. The logic here is simpler, because we can use the installed files to help guide us.
|
devpy/cmds/util.py
Outdated
site_packages = [p for p in candidate_paths if f"python{X}.{Y}" in p] | ||
if len(site_packages) == 0: | ||
print(f"No site-packages found in `{build_dir}` for Python {X}.{Y}") | ||
sys.exit(1) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It seems wrong for a utility function to call sys.exit. I would prefer it raise and the script runner catch the exception and exit
# A naming scheme that does not encode the Python major/minor version is used, so return | ||
# the first site-packages path found | ||
if len(candidate_paths) != 0: | ||
site_packages = candidate_paths[0] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should check that only one such directory exists
No tests? |
I'll add tests and see if there's a convenient way to change exiting to exceptions, thanks. |
Any progress? |
Sorry, I was a bit pre-occupied with the annual festive transition; back in the saddle now! |
c50c7c8
to
e35f35c
Compare
e35f35c
to
322fc02
Compare
OK @mattip this should do the trick! |
devpy/tests/test_util.py
Outdated
f"/usr/lib64/python{X}.{Y + 2}/site-packages/", | ||
], | ||
) | ||
util.get_site_packages(build_dir) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should this check that the returned value is the one expected?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, it should! Done.
Thanks. Looks good, maybe a bit of test improvement possible but fine to do that in subsequent PRs. As this matures, it would be good to add a version and put it on PyPI |
I added a test for return values. I will add testing on Windows in another PR; it may require a bit of tweaking to get right. |
Thanks |
On Linux, you get python3.6/site-packages or python3/site-packages. This helps to ambiguate these paths for different versions of Python.
On Windows, it is typically \usr\Lib\site-packages, so we cannot rely on the version being present.