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

[EricR86]

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]

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]

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

• Use a workaround in your setup.py to enforce build capability at setup.py runtime (see example)
• Provide wheels and/or a build environment as suggested through the suggestion in PR 134

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]

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

Github actions for:

• A source release to keep things as close to as it is currently
• A wheel release targeting a minimum python 3 version and a minimum numpy version
  • This would remove the issue of having numpy on the system before a build needed to occur

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]

@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]

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