Skip to content

Provide a way to pass custom flags to pip wheel #120

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

Closed
astrofrog opened this issue Jan 7, 2019 · 5 comments
Closed

Provide a way to pass custom flags to pip wheel #120

astrofrog opened this issue Jan 7, 2019 · 5 comments

Comments

@astrofrog
Copy link
Contributor

astrofrog commented Jan 7, 2019

I maintain some packages (e.g. fast-histogram) for which I make use of pyproject.toml to define build-time dependencies (as per the new PEP 518):

[build-system]
requires = ["setuptools", "wheel", "numpy"]

Now cibuildwheel does the following:

pip install numpy==1.12.1
pip wheel fast-histogram

The issue is that pip wheel by default will actually re-install numpy because it's defined in pyproject.toml and will actually compile the package over a more recent version of numpy. I'm not sure of the motivation for this behavior, but the solution is to run pip wheel with the --no-build-isolation option.

So I think either --no-build-isolation should be added by default to the pip wheel commands here, or if you don't agree, it would be nice to at least have a way for users to add flags to pip wheel (the first is in my opinion the better option because, in the same way that you use --no-deps to ignore install_requires, you basically want to force pip to really not install any dependencies if a pyproject.toml file is present)

@joerick
Copy link
Contributor

joerick commented Jan 8, 2019

Hmm, interesting. As I understand it, the build isolation features in pip are designed to encourage reproducible builds among python packages i.e. remove dependency on stuff that just happens to be there at build time. So the isolation means that only the stuff declared is available during the build. Now in your case, the BEFORE_BUILD installed numpy isn't available to the build because of this. (Just thinking aloud, correct me if I'm wrong!). An option to add flags could be possible, but I have a couple questions

  • Why do you need the 'install numpy' step in BEFORE_BUILD ?
  • What's the problem with installing it in both places? Build time, or something more?

Thanks

@astrofrog
Copy link
Contributor Author

@joerick - for packages that have C extensions that use Numpy, the usual approach is to build wheels against the oldest supported Numpy version and the wheel will then work with all versions more recent that this. If you do the opposite, and e.g. compile fast-histogram against Numpy 1.15 and then try and install Numpy 1.12, it work work (Numpy will complain that the ABI version it was compiled against - 0xc, is more recent than the installed version of Numpy - 0xa). This is why I need to install an old version of Numpy before the build and why I need to disable build isolation. Basically, currently with cibuildwheel we can only build wheels that work with the latest version of Numpy, not older versions.

@joerick
Copy link
Contributor

joerick commented Jan 8, 2019

@astrofrog did you try specifying the numpy version you want in the build-system section of pyproject.toml? I'm thinking something like this should work--

[build-system]
requires = ["setuptools", "wheel", "numpy==1.12.1"]

(That said, the use of build isolation in pip looks like it's reducing BEFORE_BUILD's usefulness. Since that's the way things are going (after PEP 518), I don't want to blanket disable build isolation if I can help it. Though I can see an option being useful in the transition period. interesting reading at scipy/scipy#8734)

@astrofrog
Copy link
Contributor Author

@joerick - ah interesting, I'll take a look at the scipy and pip discussions.

@astrofrog
Copy link
Contributor Author

Now that I understand PEP517/PEP518 better, I'm going to close this since the build isolation is indeed desirable!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants