Skip to content
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

how to build a package locally so that conda will not to try to replace it with anaconda one? #3324

Closed
stas00 opened this issue Dec 15, 2018 · 1 comment
Labels
locked [bot] locked due to inactivity stale::closed [bot] closed after being marked as stale stale [bot] marked as stale due to inactivity

Comments

@stas00
Copy link
Contributor

stas00 commented Dec 15, 2018

tl;dr - how to tell conda/conda-build to not upgrade/downgrade a given package if the version+arch match the package on anaconda, letting the user assume responsibility over potential issues. or perhaps being able to tell conda not to upgrade/downgrade certain pip-installed packages as long as the versions match.

Here is the full question/request:

Here is a complex situation.

You may know that Pillow has a Pillow-SIMD fork that does some image processing much faster. The culprit is that it has to be built from source by each user to her specific cpu specification. I.e. there is no way to pre-build binary versions since there are hundreds of different CPUs and the package managers don't support this anyway.

The problem is that if I build Pillow-SIMD as a pip package named Pillow locally and install it, while pip will not try to overwrite it, conda will overwrite it on any conda package install/update that requires Pillow. So one needs to watch every conda install/update and rebuild Pillow-SIMD all the time. And it's complicated, since rebuilding it requires removing jpeg, libtiff, installing libjpeg-turbo, building/installing Pillow-SIMD and then reinstalling libtiff.

I next tried to build Pillow-SIMD as a local conda Pillow package and install it. But no matter what I do conda still tries to either downgrade or upgrade the locally built/installed Pillow to the anaconda' binary of the same.

The version and arch are identical, but some files are different - since it's a faster replacement for Pillow.

I understand why this is happening - to ensure that the whole system is consistent and all dependencies are exact.

There needs to be a way for a user to tell conda that she chooses to use this version of a package, accepting the responsibility for any problems. So if I installed my own version of Pillow==5.3.0, I don't want conda to replace it with a pre-made version on anaconda, no matter what. So that if there is package XYZ that relies on anaconda's Pillow==5.3.0, and I install it and it breaks it's my responsibility. We already have --force so it's not like users can't shoot themselves in a foot.

I'm not sure whether this better belongs to the builder or the installer, so perhaps one of the two:

conda-build --supercede-others <local package>
conda install --supercede-others <local package>

Actually, an even easier solution, would be to be able to tell conda not to upgrade/downgrade certain packages installed by pip, as long as versions match. So it'd be sort of a --force extension.

conda trustpip <installed pip package>

So just like pip respects conda packages and doesn't overwrite them if the versions match, a user will have a way to tell conda to respect certain pip packages and do the same. I think I like that idea the best. I have no idea, of course, how complex that would be to implement.

I hope my explanations and the need make sense.

For those who are curious there is a detailed attempt at solving this problem here, including code:
uploadcare/pillow-simd#44 (comment)

Thank you.

edit: this seems to help a lot:

conda config --add channels ${CONDA_PREFIX}/conda-bld/

but more testing is needed.

@github-actions
Copy link

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

  1. Verify that you can still reproduce the issue at hand
  2. Comment that the issue is still reproducible and include:
    - What OS and version you reproduced the issue on
    - What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!

@github-actions github-actions bot added the stale [bot] marked as stale due to inactivity label Dec 30, 2022
@github-actions github-actions bot added the stale::closed [bot] closed after being marked as stale label Jan 30, 2023
@github-actions github-actions bot added the locked [bot] locked due to inactivity label Jan 30, 2024
@github-actions github-actions bot locked as resolved and limited conversation to collaborators Jan 30, 2024
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
locked [bot] locked due to inactivity stale::closed [bot] closed after being marked as stale stale [bot] marked as stale due to inactivity
Projects
None yet
Development

No branches or pull requests

1 participant