search

conda-forge / ipython-feedstock

A conda-smithy repository for ipython.
BSD 3-Clause "New" or "Revised" License
2 stars 34 forks source link

Current default install still broken (jedi-pin ignored by solver) #127

Closed h-vetinari closed 3 years ago

h-vetinari commented 3 years ago

Despite #118, conda ends up pulling in the older build number with the newer (broken) jedi, which is causing a whole lot of pain for users.

>conda create -n test python=3.8 ipython
[...]
The following packages will be downloaded:

    package                    |            build
    ---------------------------|-----------------
    ipython-7.12.0             |   py38h5ca1d4c_0         1.1 MB  conda-forge
    jedi-0.18.0                |   py38haa244fe_2         931 KB  conda-forge

This is a bug in conda: https://github.com/conda/conda/issues/10483 (incidentally, mamba does it correctly).

While upstream has said that a new fixed release is imminent, this is more than 2 weeks ago already, and in the meantime, everything remains broken.

There's a commit we could carry as a patch (allowing us to unpin jedi, by which time the conda-bug should be irrelevant), but I'm not sure how compatible this would be across jedi-versions, and I would consider patching the patch based on jedi-version to be a bit too much to do on the cf-side (though of course it would be possible).

In any case, ipython is one of the most widely used packages, so having this broken for so long is not great. @conda-forge/ipython @conda-forge/core

CJ-Wright commented 3 years ago

Sounds like this should go in as a repodata patch?

jakirkham commented 3 years ago

Was writing the same thing as CJ. Basically this would involve a PR to this repo. Is this something you would be able to pick up? Would look over some of the other PRs there to get a sense of how they work.

h-vetinari commented 3 years ago

When are the repodata patches expected to take effect? I retried now >8h later, and am still getting jedi 0.18...

isuruf commented 3 years ago

It doesn't for me.

h-vetinari commented 3 years ago

Ah, hadn't looked at the channel source, the problem is that anaconda isn't patched, so the same problem then appears with the main package. It works with strict channel priority, but not without.

conda create -n test python=3.8 ipython
[...]
  decorator          conda-forge/noarch::decorator-4.4.2-py_0
  ipython            pkgs/main/win-64::ipython-7.19.0-py38hd4e2768_0
  ipython_genutils   conda-forge/noarch::ipython_genutils-0.2.0-py_1
  jedi               conda-forge/win-64::jedi-0.18.0-py38haa244fe_2
  openssl            conda-forge/win-64::openssl-1.1.1i-h8ffe710_0
h-vetinari commented 3 years ago

This issue should be reopened, because the default for most users is still non-strict channel priority.

isuruf commented 3 years ago

There's nothing we can do and we recommend strict channel priority due to this.

h-vetinari commented 3 years ago

There's nothing we can do

We could patch the package in the feedstock (not that I'm saying we should), or talk to the anaconda folks to yank their 7.19.0_1 build, etc.

In the meantime, this issue should IMO stay open until there's a new ipython release, because it still affects a large part of users. At least they'll find that they can fix it with strict channel priority (I also posted this on the ipython issue).

isuruf commented 3 years ago

Please open an issue in AnacondaRecipes/ipython-feedstock. As I said earlier, there's nothing we can do.

We could patch the package in the feedstock

What are you talking about? Please explain.

h-vetinari commented 3 years ago

We could carry https://github.com/ipython/ipython/commit/dcd9dc90aee7e4c5c52ce44c18e7518934790612 and drop the jedi pin. But then there's the question of compatibility across jedi-versions, and since upstream is not targeting this patch for the 7.x branch, it's not what I'm suggesting.

I just wanted to say that there are things we could (theoretically) do - at least leaving this issue open.

isuruf commented 3 years ago

We don't support non strict channel priority at all. Users who use that are on their own.

h-vetinari commented 3 years ago

We don't support non strict channel priority at all. Users who use that are on their own.

I understand the realities of the situation. Just saying it's still not a good user experience if the (still, AFAIK) most widespread default isn't working. But then, there are also limits to how much CF should be expected to do. This is a problem that should be fixed upstream...

CJ-Wright commented 3 years ago

We could create a conda-forge-helper pkg that creates/updates the .condarc to be conda-forge supported. This may be a massive overreach, but it could make the user experience better (while still allowing advanced users to opt out by never installing it). The existing conda-forge conda distributions may already do this (by setting it as a default).

jakirkham commented 3 years ago

cc @anaconda-pkg-build (for vis)

chenghlee commented 3 years ago

We've patched the repodata.json on defaults to fix this.