ipython: Last jedi release (0.18.0) is incompatible with ipython (7.19 and 7.18 tested); reason - column arg was deprecated, and now removed

As a temporary fix for anyone just trying to get things working again:

pip install jedi==0.17.2

---

It would be really nice if you could quickly release a 7.19.1. (It’s already fixed on master).

Sorry for that. I did not realize that IPython with that fix was not released yet. I usually test IPython completions before doing a Jedi release, but not this time 😕. It will probably also not happen in the future anymore, because I’m going to release Jedi 1.0 soon, so this is probably the last time for a long time that you have to deal with deprecations in Jedi.

Still wish you a Merry Christmas!

Because people at this point probably don’t scroll up to my comment (https://github.com/ipython/ipython/issues/12740#issuecomment-751273584), this is what you should do temporarily:

pip install jedi==0.17.2

I’ll try to release 7.20 soon; I’ve make it compatible with jedi 0.18 as pip also use a resolver and so pinning is not an option as pip would be free to downgrade IPython and keep jedi 0.18 which will brake.

Right now the limiting factor for the release is writing the what’s new.

I am really disappointed that the maintainer of a great product as Ipython has such a limited knowledge about the problem. The fact that Ipython has not been pinning jedi means that any version of it released in the past that depends on jedi is at its merci to stop working as soon as a no backwards compatible change is introduced and used in Ipython. By changing Ipython to make it jedi 0.18 compatible and releasing 7.20 you make that 7.20 operational today. If tomorrow jedi makes another backwards incompatible change We will be screwed again. And you can’t blame jedi for backwards incompatible changes because it is not even 1.x and you are not even pinning the major. You are calling for trouble.

I am really disappointed that the maintainer of a great product as Ipython has such a limited knowledge about the problem. The fact that Ipython has not been pinning jedi means that any version of it released in the past that depends on jedi is at its merci to stop working as soon as a no backwards compatible change is introduced and used in Ipython. By changing Ipython to make it jedi 0.18 compatible and releasing 7.20 you make that 7.20 operational today. If tomorrow jedi makes another backwards incompatible change We will be screwed again. And you can’t blame jedi for backwards incompatible changes because it is not even 1.x and you are not even pinning the major. You are calling for trouble.

I’m amazed that someone that contribute squat is telling me what i’m doing wrong without tryign to really think about the problem.

• Say I pin IPython 7.20 to jedi <0.19 , and david release jedi 0.19.
• pip is no free to say “hey let’s install jedi 0.19 and downgrade IPython to 5.x”.
• Bam you are wrong™️ . 💎 🚀 🌕

And second the change of API were in jedi 0.17 with deprecation warnings and fix in master close to a year ago; I thought that by now 8.0 would be out.

FYI about me know nothing about versioning:

• I spend month implementing on pushing the python_requires logic in pypi, and in pip to make sure when IPython dropped it did not break for Python 2 users
• I’m one of the regular advocate to have version medata data and package content to be separated in conda/pypi for this exact reason.
• It’s not because something seem obvious that it’s correct.

You could have just asked in for a question “why are not you pinning to <0.19 starting with IPython 7.20”, to which I would have responded. So not only you are impolite and haven’t done your research, everybody see you incorrectly assume you know better than others and you’ve lost all credibility.

✋ ⬇️ 🎤

I’ll try to release 7.20 soon; I’ve make it compatible with jedi 0.18 as pip also use a resolver and so pinning is not an option as pip would be free to downgrade IPython and keep jedi 0.18 which will brake.

Right now the limiting factor for the release is writing the what’s new.

https://github.com/ipython/ipython/commit/dcd9dc90aee7e4c5c52ce44c18e7518934790612

The code has been already updated, but 7.19.0 did not include this. 😦

By the way, a 7.19.1 release with the dependency jedi<0.18.0 would also suffice.

@Carreau Thanks a lot! I guess the next release is going to be 1.0 anyway, so it shouldn’t happen again. We might then think about pinning jedi < 2.0.0 (which is probably years away).

In general for all people like @mostealth: If you are worried about older versions breaking: Pin your dependencies! The Python packaging system is still in a bit of a problematic state. The devs are doing a good job trying to turn it around, but there is a lot of technical debt from years ago. Keep in mind they want to keep backwards compatibility with a lot of old and new things. Just a enumerating a few things to show how complicated it is: eggs, wheels, explicit namespace packages, setuptools, distutils, import hooks, import meta paths, importlib, easy_install, venvs, virtualenvs, zip imports, freezed packages, source packages for C/C++ libraries and a lot of other things that I don’t even know or remember anymore.

Most of you guys complaining don’t really understand how hard certain things are if you consider all consequences. Read about Chesterton’s Fence and try to understand why you shouldn’t want something changed unless you understand why it is that way in the first place.

just adding a +1 to this issue, it totally disables tab completion in Jupyter, so worth pinning 0.17.2 until resolved

The following works in ipython/jupyter. I assume it gets jedi out of the way of the built-in completer. Good enough for me until fix is released.

%config Completer.use_jedi = False

So essentially you say as there are problems with pip resolver and in some cases it will not be able to upgrade correctly I will completely ignore the problem and not try to solve other uses cases that I can. Yes, fixing Ipython to work with the latest jedi is correct and pinning is needed as well. Most use cases of Ipython will be install Ipython on a new environment. Should you pin, your 7.20 will work always. Ignore it and you depend on your dependencies. The reason I didn’t ask why you are planning to do what you are planning to do is because I know that solution is suboptimal. It doesn’t matter what work or knowledge has been accumulated in the past, that says nothing.

As a temporary fix for anyone just trying to get things working again:

pip install jedi==0.17.2

It would be really nice if you could quickly release a 7.19.1. (It’s already fixed on master).

Sorry for that. I did not realize that IPython with that fix was not released yet. I usually test IPython completions before doing a Jedi release, but not this time 😕. It will probably also not happen in the future anymore, because I’m going to release Jedi 1.0 soon, so this is probably the last time for a long time that you have to deal with deprecations in Jedi.

Still wish you a Merry Christmas!

note: in anaconda, this has to be done in the same kernel you’re using from within the jupyter notebook, not the one you’re using the jupyter notebook command from!

took me about 30 minutes to finally figure that one out once i found @davidhalter’s pip install tip (i used conda install jedi==0.17.2 instead of pip).

thank you all!

@rsokl Actually, anaconda fixed their repo data as well, so now it works out of the box again 🥳

FYI https://github.com/ipython/ipython/pull/12751#issuecomment-758065462

@tik9 Does installing from master work for you?

pip install git+https://github.com/ipython/ipython

If so, whenever ipython releases a new version, it will be fixed for everyone.

@rsokl There was one other way I hadn’t thought about - fixing the conda-forge repodata directly. This was done yesterday, and means the problem is fixed within conda-forge, i.e. when using strict channel priority (ignoring the main anaconda package that still has the same problem) - which unfortunately is not the out-of-the-box behaviour for conda though.

You can either do this for a single install (e.g. conda create -n test --strict-channel-priority python=3.8 ipython), but the recommended way (see e.g. here) is persisting that setting with

conda config --set channel_priority strict

As a temporary fix for anyone just trying to get things working again:

pip install jedi==0.17.2

It would be really nice if you could quickly release a 7.19.1. (It’s already fixed on master).

Sorry for that. I did not realize that IPython with that fix was not released yet. I usually test IPython completions before doing a Jedi release, but not this time 😕. It will probably also not happen in the future anymore, because I’m going to release Jedi 1.0 soon, so this is probably the last time for a long time that you have to deal with deprecations in Jedi.

Still wish you a Merry Christmas!

thanks a lot

@rsokl I raised an issue with conda itself, since it’s probably too much (though not impossible) to do this on the conda-forge packaging side (in a way that’s also compatible across several jedi-versions) - raised an issue to discuss that too…

@Carreau said he’d make a new release soon, which would of course also solve things.

In the meantime, the “hand-holding” guide should be as easy as conda install ipython "jedi<0.18" (the quotes are important though, as otherwise you end up piping to nowhere).

What the timeline looks like for this getting fixed for mainline conda users?

I ask because I have an online outreach course spinning up in about four days, meaning that 600+ highschool students are going to be encountering the “now hit <TAB> to autocomplete 😃” portion of their virtual course, and it is going unceremoniously bomb them out of ipython.

Downgrading jedi is easy enough for me, but much harder for someone who has never written a line of code before.

As a temporary fix for anyone just trying to get things working again:

pip install jedi==0.17.2

It would be really nice if you could quickly release a 7.19.1. (It’s already fixed on master).

Sorry for that. I did not realize that IPython with that fix was not released yet. I usually test IPython completions before doing a Jedi release, but not this time 😕. It will probably also not happen in the future anymore, because I’m going to release Jedi 1.0 soon, so this is probably the last time for a long time that you have to deal with deprecations in Jedi.

Still wish you a Merry Christmas!

Thanks

Confirmed that downgrading jedi to 0.17.2 fixed the issue for me as well. Thanks @davidhalter

@NeilGirdhar , when doing pip install git+https://github.com/ipython/ipython

It seems to work, I still have to update to the current Jedi.

Posted a pr to pin the dependency as suggested: #12746

pip is no[w] free to say “hey let’s install jedi 0.19 and downgrade IPython to 5.x”.

That would indeed be unfortunate, the resulting setup would be not only broken, but out-of-date to boot. Can that happen when running pip install ipython in a fresh environment? I would naively assume that this would fetch the latest version of IPython and figure out the dependencies from there, i.e. honoring jedi < 0.19. But that assumption is probably wrong?

As maintainer of my own small Python package with moderately complicated dependencies, I feel like I should read up on this 😃 Any tips on good material on this topic?

@Carreau: dude, you rock!

Welp, spoke too soon, conda-forge has the same problem (basically, the higher build number seems to lose against having one dependency have a higher version, which is not how it should work. A possible solution would be backporting https://github.com/ipython/ipython/commit/dcd9dc90aee7e4c5c52ce44c18e7518934790612 to the feedstock, but that really should happen here first).

Not you, but conda’s dependency resolver. This is a problem and has been for years. (Sorry for the off-topic, but I could not resist)

Have you heard of mamba already? It has a rewritten resolver but is fully compatible with the conda-ecosystem. Not only does it solve the biggest problem of the conda-solver (speed), but it also correctly sets up the environment here:

>mamba create -n test python=3.8 ipython
[...]
  ipython                             7.19.0  py38hc5df569_2      conda-forge/win-64       1 MB
  ipython_genutils                     0.2.0  py_1                conda-forge/noarch      21 KB
  jedi                                0.17.2  py38haa244fe_1      conda-forge/win-64     944 KB
[...]

When is the team going to fix this? In just a month hundreds of users have encountered this issue.

I wonder, when you have a dependency (jedi) that is in version 0.x.y (not reached major 1), if it is not wiser to pin the minor as >=0.17,<0.18.

installing 0.17.2 of jedi also worked for me. Was chasing my tail trying to figure out why it wasn’t working in a new virtual environment, glad to have found this! Hope the fix is out soon. Luckily this showed up as the top link in Google for me when searching “ipython init got an unexpected keyword argument ‘column’”.

Thanks a lot. I thought my shell was broken. Every time when I tried to use tab completion in IPython it crashed. Glad I found a solution.

Thank you @Carreau. Finally someone who does not follow the church of pinning stuff without thinking about the consequences. Here is another case why pinning to older versions is not always a good idea: https://github.com/palantir/python-language-server/issues/898#issuecomment-770399215.

Unfortunately the Jedi and Parso pair are a frequent cause for headaches for packagers. Not only pip and conda, but also Linux distributions. I am looking forward to a more stable API once they reach 1.0.

@mostealth Obviously you have a different perspective on that matter. That’s fine. However, it seems rather unproductive to dissipate the time and energy of productive people like @Carreau with pointless discussions. If you have deeper insights I see the following options: You can fork the project, file a PR or just sate your improvement suggestion in a way that is arguable, maybe in a dedicated issue.

For the rest of us I would suggest to basically ignore distracting comments which contain neither helpful information nor constructive criticism, but instead spread insults and negative emotion. Reactinv with 👎 should be enough attention for such comments.

Nice! I just confirmed this on my end. I guess I’ll keep those callout boxes up on PLYMI for a bit in case folks had already installed anaconda.

@gkuenning I just uploaded the downgrade instructions to Python Like You Mean It.

Under: Information Introduction to Python and under Jupyter Notebooks

So the packages are definitely there (notice the _1 build number), but interestingly, are not seeing much (or even any) downloads

My totally uneducated guess (because I never understood the internals of the conda resolver): conda sees the conflict for jedi==0.18.0 and ipython-7.19.0-..._1 and instead of resolving it by jedi==0.17.2 and ipython-7.19.0-..._1 it chooses jedi==0.18.0 and ipython-7.19.0-..._0

Am I missing something here?

Not you, but conda’s dependency resolver. This is a problem and has been for years. (Sorry for the off-topic, but I could not resist)

What the timeline looks like for this getting fixed for mainline conda users?

You might be successful if you ask the conda maintainers to yank jedi 0.18 from their repos.

Releasing a new Jedi version might be easier than waiting for the next IPython release.

@davidhalter, how about making a one time exception in this case and reintroducing the deprecated features, the lack of which breaks IPython (and a few more packages) in a Jedi 0.18.1?

I guess pinning jedi to 0.17.2 should be added to the readme. Anyone think I should open a PR for that? 😸

Can you explain what you mean by “same kernel …” vs “using the jupyter notebook …” i.e., will conda install jedi==0.17.2 from the shell command line do the trick? (it seems to)

You can run Jupyter in one env and use it with a kernel from another env. See for example this SO question. Jedi version of the latter env matters. If you are not aware of this, you probably use one conda env for jupyter and kernel.

pip install -U jedi==0.17.2 parso==0.7.1

Hi everyone, I’ve stumbled on this issue while creating docker images for myself. If I understand correctly from this comment the problem has already been solved on master, but so far no release including the fix has been issued. In order to better organize my own work, may I know when do you plan a new release? Somebody here was suggesting to quickly release 7.19.1, including this patch, is it still an option?

Thanks @bl-ue

For reference, the autocomplete on my Jupyter notebook wasn’t working and I was getting this same error on the terminal.

And now it’s working as expected after downgrading jedi to 0.17.2 by just executing the command @bl-ue mentioned.

Finally found a solution! thank you @davidhalter 🎉

I had the same problem with ipython and thanks to the solution of @davidhalter , it works again. 👍

@davidhalter Thanks for your solution. it finally work.