-
-
Notifications
You must be signed in to change notification settings - Fork 9.8k
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
ENH: Add platform indepedent lib dir to PYTHONPATH #8027
Conversation
This allows using runtests.py with pure python packages. I doodled the change based on my local version, so we shall wait and see if travis chokes up.
Could you expand on the use case for this? |
Yes. I've been using runtests.py for testing various packages. (Including testing a few mpi4py based packages where I added an extension to run the payload with mpirun; but that's another thread). Unfortunately when the package does not contain a binary extension, it can not correctly locate the path of the installed package. (At least on a Fedora system; I am not sure about Debian based systems) It turns out on Fedora, the arch-independent python packages are installed to the lib/ directory; but runtests.py insists to look for packages in the lib64 directory (due to plat_specific=True) An example is at https://github.com/bccp/bananaplots -- runtests.py there has been modified. I tried a few approaches but this one, adding both path seems to be the shorted solution. The alternative was to automatically decide whether the package is arch-independent. I could not find a way of doing this. |
A related question, is there a possibility runtests.py be made into a module in numpy.test / numpy.tests ? Then projects can import and run the main function instead of copying the script over. |
Good question. SciPy also has a version of runtests. @pv Would it make sense to make runtests more universal? |
The patch itself seems fine to me. I think it would make more sense to split runtests.py off into an independent project (possibly vendored into individual projects like numpy and scipy) than to add it to numpy's public api with all the resulting commitments. |
@rainwoodman Might be worth pursuing @njsmith's suggestion and putting something up on PiPI. The current |
My main objection to this patch is that I don't want to get into the business of supporting other projects. That said, I suppose the proposed changes are otherwise harmless. |
Isn't there is already a commitment in numpy to provide testing facilities for scipy? To address @charris's concern over the extra commitment, I'd re-purpose this patch to "removing the assumption in runtests.py that numpy has binary extensions." The code still needs a line of comment to avoid being removed by maintainers. I'd be happy to put something up on PyPI, but adding another dependency to numpy is probably going to face a lot of opposition. In that sense, the new thing shall probably be in a single runnable format such that downstream projects can reuse copy and paste. Any suggested names? |
I was already starting to type "good idea", but after checking the difference between |
this patch is fine and small, so I propose to merge it. making a separate |
OK, let's put this in. Thanks @rainwoodman . |
This allows using runtests.py with pure python packages.
I doodled the change based on my local version, so we shall wait and see if travis chokes up.