-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Latest pip versions doesn't support --build option #1831
Comments
Confirmed. I upgraded pip on my workstation and tested this:
|
No response on my comment about fpm using --build -- pypa/pip#8333 (comment) We'll probably have to find a workaround instead of having pip help us. |
I have same probs, and now im building packages this this way (it's enough for my local needs):
Hope it helps in finding workaround |
@jordansissel Any update or workaround on this? Using an outdated pip version is becoming harder to maintain as well. |
@Jayfrown I haven't found a solution yet. I think we can remove the |
The above comment wasn't quite clear, sorry. The For newer pip versions, if I try removing the |
Previously, fpm would use `pip download ... --build ...` to instruct pip to unpack a given python package to a specific directory for the purpose of running something like `python setup.py` from it. However, somewhere in 2021, pip removed this flag. First, I think, it was deprecated and ignored, then finally removed. One reference to this removal in the upstream pip project is this issue: pypa/pip#8333 Without `--build`, pip will place a single tarball in the destination directory. Fpm cannot easily predict the name of this file because we don't know the "real" name of the python package nor do we know the version number being downloaded. For example: ``` % python3 -m pip download --no-binary :all: --no-deps --no-clean django ... Successfully downloaded django % ls Django-4.0.4.tar.gz ``` Best guess: * we can expect exactly one file in the previously-empty target directory * we can also expect that it is a .tar.gz I don't know if these guesses are always correct, but it's a start. As of this commit, the following command generates a Debian package: `fpm -s python --python-bin python3 -t deb django` Prior to this commit, with a newer version of pip, the command would fail. Fixes #1831
I think this works: #1896 |
Previously, fpm would use `pip download ... --build ...` to instruct pip to unpack a given python package to a specific directory for the purpose of running something like `python setup.py` from it. However, somewhere in 2021, pip removed this flag. First, I think, it was deprecated and ignored, then finally removed. One reference to this removal in the upstream pip project is this issue: pypa/pip#8333 Without `--build`, pip will place a single tarball in the destination directory. Fpm cannot easily predict the name of this file because we don't know the "real" name of the python package nor do we know the version number being downloaded. For example: ``` % python3 -m pip download --no-binary :all: --no-deps --no-clean django ... Successfully downloaded django % ls Django-4.0.4.tar.gz ``` Best guess: * we can expect exactly one file in the previously-empty target directory * we can also expect that it is a .tar.gz I don't know if these guesses are always correct, but it's a start. As of this commit, the following command generates a Debian package: `fpm -s python --python-bin python3 -t deb django` Prior to this commit, with a newer version of pip, the command would fail. Fixes #1831
#1896 should solve this. |
fpm 1.15.0 is released and contains this improvement. |
Got the related error on Fedora 34 (Python v3.9). Running command:
fpm --debug -s python -t rpm --debug --iteration 1 --python-install-lib /usr/lib/python3.9/site-packages --python-bin /bin/python3 --python-package-name-prefix python3 --no-python-fix-name --debug-workspace gcalcli
The result looks like:
The text was updated successfully, but these errors were encountered: