-
-
Notifications
You must be signed in to change notification settings - Fork 14
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
4.1 #3
4.1 #3
Conversation
Hi! This is the friendly automated conda-forge-linting service. I just wanted to let you know that I linted all conda-recipes in your PR ( |
Windows builds failed, but I don't understand why.
|
Explanation: conda-forge/jupyter_core-feedstock#5 (comment) Temporary workaround: minrk#1 |
Do not use pip for now
Since conda-build 1.21.11 is producing packages that cannot be installed by any released version of conda, I would rather pin conda-build than remove the call to pip while this gets worked out. What's the best way to do that (@msarahan?) |
Sorry, but I don't think that reverting conda build will work. It's not that conda build changed how pip behaves, but rather just that it now properly detects binary prefixes embedded in the entry point executables. Because pip is embedding these prefixes into the executables, you instead need to figure out when pip started doing that, and pin pip. I am pretty sure that older versions of conda build will still have broken entry points, and moreover they simply won't be fixable by any version of conda. I have also thought about using pip on Mac and Linux, but the old way on Windows to avoid these embedded prefix exes, until the conda support for them is more generally available. I am not sure if that is palatable to you. |
9232f56
to
3fc208a
Compare
workaround conda bug in normal entry points
No description provided.