-
Notifications
You must be signed in to change notification settings - Fork 3k
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
--no-binary :all:
option not taken into account when building from source
#7248
Comments
Hi @SylvainCorlay. I am not able to reproduce this on Ubuntu 18.04 with Python 3.7.2 with either pip 19.1.1 or 19.3.1 with: repro.sh
Output
Note in the output that pip indicates it is not building a wheel for the invocations that have Can you please adapt the script above to demonstrate your issue? One approach could be to make the small project look similar to the project for which you're having the issue. |
The package for which I am seeing this issue is ipykernel I have to disable build isolation for this package because
The output shows
|
The arguments seem to be out of order, can you please try
Locally that works for me without building wheels. Also please note that the issue with flit installing from sdist should be fixed by #6606, which was included in pip 19.3.1. |
Obviously I meant I am still seeing the wheel being built. |
Sorry, any little detail can cause issues like this, so we can't take anything for granted even if it may be "obvious" in a normal situation. Can you please re-run the command giving you the unexpected result with |
Output
|
Are you still having trouble reproducing the issue? |
I was able to reproduce in a container repro.sh
With output Output
With the latest version of pip (19.3.1) it builds a wheel in both cases, but I think this is the expected behavior. There are two relevant things to note here:
Can I ask what the use case is for not doing a wheel build? |
Ah, --no-binary does not stand for “don’t build a wheel”, but rather that “don’t use wheels from the index”. In PEP 517 (the build interface for that flit is implementing), the main way for flit and pip to communicate is via building wheels for installation on this machine. @SylvainCorlay does that make the situation clearer? Do you have any suggestions on how we should communicate this to the end user? |
My usecase is that I use pip to build python packages as part of the build process for conda packages.
I think that it is very important that we retain the possibility of installing package from source without building a wheel for the usecase of package managers. |
I have a bunch of questions, please bear with me.
I'll wait for those answers before diving into the rest of your comment, since they will probably provide a lot of the required context. |
For conda at least, it's fine if |
conda is a general-purpose package manager (not just for Python), and it builds packages (python packages or not) by creating a new environment (a prefix) in which dependencies are installed by conda and running the installation procedure from source in that environment. For a C++ package built with e.g. cmake, that naturally involves running cmake and make, for a Python package, that generally implies invoking the In any case, as pointed out in earlier comments, for the usecase of conda (and I presume for other package managers as well):
|
@chrahunt I am following up on this. Note: this issue will be important to most people working on packaging python packages for other package managers such as conda, apt-get etc... |
@isuruf actually I would like to build a conda package without building an intermediary wheel. |
@SylvainCorlay, to start, here is my understanding:
If that's all right, then I can provide the following guidance:
|
Thanks for your detailed answer @chrahunt. I think we have a good understanding.
This is great to hear!
I actually think that it should be possible to prevent the creation of intermediate wheels. If this is a requirement since PEP 517, I think this is regrettable.
Indeed. One case where I think it is needed is to specify full paths to kernel executables in the Jupyter kernelspec, so that they can be found even when not in the PATH. But even outside of conda, when installing in a known prefix from an sdist, the kernelspec could include the full path as expected. |
This is not going to be possible for pyproject.toml-based projects (i.e. what PEP 517 started with standardising). We're going to remove Beyond that, I don't think there's much actionable here; so I'm gonna go ahead and close this. |
Environment
Description
Disabling the building of an intermediate wheel appears to work when installing a package from and sdist (either on PyPI) or a local sdist tarball.
However, the option does not appear to be taken into account when doing
in the source directory.
Expected behavior
I expect the behavior to be the same when building an sdist or building from source in that regard.
How to Reproduce
Build a python package from source with
--no-binary :all:
and check that a python wheel is created.The text was updated successfully, but these errors were encountered: