dcd9dc9

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

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!

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

@davidhalter Thanks for your solution. it finally work.

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

Thank you for opening this issue. Happy holiday!

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

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.

Finally found a solution! thank you @davidhalter 🎉

When would the problem be fixed so that every Jedi version is compatible with ipython?

@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.

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

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

Got this issue as well. Pinning jedi==0.17.2 worked for me, thanks @davidhalter.

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!

Thank you for your solution.
I got the same issue and IPython worked after I installed Jedi

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'".

Thank you, both of you, for the useful insights and recommendations. I really appreciate it.

It sounds like I will go the route of putting a call-out box in my website that adds a hand-holding jedi-downgrading walkthrough (although, then I have to hope that the students have the awareness to repeat that step when creating new environments)

As it stands, I am dangerously close to making two "but think of the children" pleas in a single github issue, which is a violation of one of my new years resolutions.

(mamba looks cool!)

@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).

@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

Thank you, both of you, for the useful insights and recommendations. I really appreciate it.

It sounds like I will go the route of putting a call-out box in my website that adds a hand-holding jedi-downgrading walkthrough (although, then I have to hope that the students have the awareness to repeat that step when creating new environments)

As it stands, I am dangerously close to making two "but think of the children" pleas in a single github issue, which is a violation of one of my new years resolutions.

(mamba looks cool!)

@rsoki, can you post a link to your walkthrough? I think some others among us have the same problem...

BTW, "Effective Python" (2nd edition) #89 suggests using the warnings module to handle things like deprecating arguments.

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

Under: Information Introduction to Python and under Jupyter Notebooks

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

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.

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'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.

✋ ⬇️ 🎤

@Carreau: dude, you rock!

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.

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?

@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.

@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.

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: palantir/python-language-server#898 (comment).

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.

Thanks everyone for the inputs; if we want to have discussion as to why/when pinning and why when not to pin, and other I suggest we don't use the bug tracker, maybe discourse.jupyter.org; but stop adding to this particular issue.

IPython is a bit in a tough spot as it is both a library and application (in general you want to have a lock file to pin deps for applications, but be as liberal as possible when building a library).

There is also a lot of issues that arise from the fact that maintainers time and desire to maintain can come and go; I definitely thought that by sept 2020 IPython 8 would be out, and that other maintainers like @davidhalter from jedi would also welcome more testing and help.

The Python package ecosystem is also quite old; and PyPI relatively recent; the requirements and needs of today's infrastructure can also be much different than what was expected even 5 years ago. That plus it works from HPC system to end-user that are starting to program so there is a lot of difficulties there.

Thanks everyone, I've now released 7.20 feel free to open bug reports if you encounter any issues.
For now I'm going to lock this thread to avoid getting much more off topic.