-
Notifications
You must be signed in to change notification settings - Fork 3.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
Difference in binary builds between pip 19.3 and 19.3.1 #7240
Comments
Hello @iamareebjamal, If I understand correctly your |
No, the problem is not related to importlib_metadata. You change importlib_metadata to any library which is built during install Also, I can provide a pipdeptree if it helps. Many direct dependencies weren't installed as well |
It would 👍 |
https://www.diffchecker.com/ryCo05HG 19.3 info
19.3.1
|
@iamareebjamal Hi! I've edited your bug report to read more easily (shorter sentences, imperative tone) and to tone down some of the wording used. Using all caps (equivalent to shouting via text) isn't a good move when you're asking for help from volunteers who do this stuff because they find it fun. :) If you have any concerns with that, please file a new issue on pip or drop me an email on {username}@gmail.com. |
Looking at the diff between the release tags: 19.3...19.3.1 I think what broke your usecase was the fact that we fixed a major bug in PEP 517 based builds. I'd have liked to have made that fix in 19.3 but I didn't have the bandwidth to and AFAICT, that fix was fairly innocuous. I'm not sure there's anything actionable now for pip, other than acknowledging that cached docker containers that were built earlier, should be invalidated since a bug in pip's build process was fixed which affects how we can use the cache. Sorry if that sounds a little bleak but well, pip's used in so many ways that at this point, every non-refactoring patch breaks something, usually in ways that no one thought of when working on this stuff. 🤷🏻♂️ |
@iamareebjamal, in your Dockerfile please pass an explicit There was a bug fixed in #6606 (released in 19.3.1) as mentioned by @pradyunsg that now correctly builds projects that use PEP 517 without implicitly going through setuptools. This fix was causing an issue in your case because the packages that were now using PEP 517 were not picking up the prefix directory passed via |
Sorry if it felt like I was using caps to emphasize or shout. I was simply referring to |
@chrahunt If pip indeed follows semantic versioning, then its behaviour should not change between patch updates. I can add the fix from my end for sure, but this is considered a breaking change, and hence should be communicated and moved to a minor release, rather than a patch one. I understand that a major release will not be practical, but even minor releases warrant backward compatibility with feature additions. And patch updates should only fix bugs without compromising any previous behaviour About action that pip can take, I don't know if this would be considered rude or impossible as well, but most other tool authors create a new patch version with behaviour restored to surprise the least amount of users, and then introduce the fix with a minor update Reference: stripe/stripe-python#582 |
@iamareebjamal pip does not follow semantic versioning, we use calendar based versioning. See the documentation for details. Specifically, version 19.3.1 is the first bugfix release of the 3rd release in 2019. |
Well, that's sad :( Documentation update of 19.3.1 won't notify people of the issue. And they may spend days debugging the issue and may not even be able to source it to pip. This will cause a waste of time and stress. I know something might break in any patch version of pip because of its vast use case surface area, but the next section in the documentation you linked talks about It says that pip will start issuing warnings for 6 months before changing public visible behaviour. https://pip.pypa.io/en/latest/development/release-process/#deprecation-policy That is awesome! Because it is stricter than semantic versioning and would align with pip's own guidelines as well. And also follows the principle of least surprises. |
Hi @iamareebjamal. One thing I think would be completely reasonable (and that we've done in the past) is to make (and pin, if common enough) a canonical issue to communicate the best information we have on how to identify and remedy the problem. This should get picked up by search engines too, reducing any burden. To help in creating that, can you provide information on the origin of |
Sounds good enough. The maintainer who added the Thanks for the help |
Also, change to new syntax of pip for install prefix Ref: #6543 pypa/pip#7240 (comment)
Also, change to new syntax of pip for install prefix Ref: fossasia#6543 pypa/pip#7240 (comment)
Is this issue still valid or can it be closed? |
This can be closed! |
Environment
Description
We use multistage builds to make our docker image compact.
https://github.com/fossasia/open-event-server/blob/b7ba05cfaefdc257e9ae07d264044668dadffce5/Dockerfile
We are using python:3.7-alpine as base image which had pip 19.3 pre-installed.
Installing dependencies with build tools like gcc and others in the initial stage and then copying them to the later stage. This is a common practice and recommended in the docker community.
We installed the build tools and requirements using apt and pip which installed correctly using this command:
Then, we copy the installed libraries to the next stage using the command
COPY --from=builder /install /usr/local
.Now, all the libraries installed in the previous stage should be present in the next stage. Which was the case until today.
When we built the release container, it did not have
importlib_metadata
and threw ModuleError.After hours of debugging, and jumping through diffs of previously working diff environment, we found that it was not installed at all along with some other libraries. More time consuming debugging later, I found out a difference between environments. The broken environment had Python 3.7.5 and pip 19.3.1 and working one had Python 3.7.4 and pip 19.3.
A quick matrix test on Python 3.7.4 with pip 19.3.1 and Python 3.7.5 with pip 19.3 showed that indeed the problem was with pip and not Python version.
After analyzing the missing dependencies, we found out that the only ones missing were the ones that were built during the previous stage. One of which was the aforementioned
importlib_metadata
along with several other built libraries.Expected behavior
pip 19.3.1 which is a patch version should not break backward compatibility and retain the behavior as 19.3.
How to Reproduce
OR
docker build . -t eventyay/open-event-server
docker run -it --entrypoint /bin/sh eventyay/open-event-server -s
pip freeze | grep import
python:3.7-alpine
topython:3.7.4-alpine
or addpip install pip==19.3
in the firstRUN
step to lock pip, and repeat steps 2-4 and you'll find the libraryOutput
The text was updated successfully, but these errors were encountered: