deeptools / pyBigWig

A python extension for quick access to bigWig and bigBed files
MIT License
218 stars 49 forks source link

Can't enforce numpy features when pyBigWig is used as a dependency in downstream package #133

Closed EricR86 closed 1 year ago

EricR86 commented 2 years ago

There's an issue when numpy features are necessary for downstream packages of pyBigWig.

The current setup.py checks that numpy is currently in the python path to build the necessary extension. There is currently no way of ensuring numpy is on the python path when pyBigWig is installed as a dependency in another package. Both setup_requires and build_requires is not sufficient since it covers only the current package and not its dependencies. Even if numpy manages to technically get installed before pyBigWigwhen dependencies are installed it is still not sufficient.

Ideally it would be great to have numpy features available through something like extra_requires providing an optional dependency. Ideally being able to specify something like pyBigWig[numpy].

Currently the only workaround is to ensure that numpy is installed first to the environment, then pyBigWig or any package that is downstream of it.

Thanks for your time.

dpryan79 commented 2 years ago

That's a clever idea. I've started on that here: https://github.com/deeptools/pyBigWig/pull/134

I can't say I'm very familiar with optional requirements in python, do you think what I've done there will suffice or do you have different suggestions there?

EricR86 commented 2 years ago

So I have some follow-up suggestions for this particular issue since having an optional build requirement, that when necessary for anything downstream, will unfortunately not work:

  1. Make numpy a strict build requirement
  2. Provide alternative packages in pypi for numpy and non-numpy versions. The numpy version will still need one of the solutions listed in 1. above

It also worth noting that numpy.distutils will be deprecated in Python 3.12 so unfortunately the build will eventually break as-is for users.

EricR86 commented 1 year ago

Would you be open to a pull request on this issue? Here's what I would suggest:

Github actions for:

I've recently done all of the leg work and research for this for a recent release of my own (except the numpy targeting).

These changes would likely update the build mechanisms to use the new build frontend with pyproject.toml and keeping setuptools as the build backend.

michaelmhoffman commented 1 year ago

@dpryan79 Would you be willing to consider a pull request to outline what @EricR86 suggests above? We want to use pyBigWig as a new transparent backend for Genomedata to use bigWig data without conversion, but this issue is keeping us from continuing to have a simple way of installing via PyPI. Thanks for the great package!

dpryan79 commented 1 year ago

The wheels for this should now resolve this issue. If not, let me know.