ENH: Add platform indepedent lib dir to PYTHONPATH

[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.

[charris]

Could you expand on the use case for this?

[rainwoodman]

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).
Overall, when the package contains a binary extension, runtests.py works great.

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.

[rainwoodman]

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.

[charris]

Good question. SciPy also has a version of runtests. @pv Would it make sense to make runtests more universal?

[njsmith]

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.

[charris]

@rainwoodman Might be worth pursuing @njsmith's suggestion and putting something up on PiPI. The current runtests looks to have some, fairly soft, numpy dependencies for things like bench marking. Having it work with, say, pytest might also be helpful. This looks like the sort of thing where a discussion on the mailing list might be useful to see if there is any interest from other projects.

[charris]

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.

[rainwoodman]

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?

[rgommers]

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.

I was already starting to type "good idea", but after checking the difference between runtests.py in numpy and scipy I'm not sure. There's stuff for benchmarks, refguide check, project name and project-specific filenames that make it hard to just vendor. And vendor + modify is basically the current model.

[rgommers]

this patch is fine and small, so I propose to merge it. making a separate runtests.py package with a template of stuff to modify can still be done of course, but that's separate to this PR.

[charris]

OK, let's put this in. Thanks @rainwoodman .