Update Jedi constraint in Spyder 3 to avoid issues when updating to Spyder 4

[goanpeca]

Checklist

• [x] Used a fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [ ] Reset the build number to 0 (if the version changed)
• [ ] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

Fixes spyder-ide/spyder#11581

[conda-forge-linter]

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 (recipe) and found it was in an excellent condition.

[goanpeca]

Fixes https://github.com/spyder-ide/spyder/issues/11581

[goanpeca]

@ccordoba12 not sure what the problem is. Line endings on the patch file?

[ccordoba12]

@jjhelmus, this hotfix to Spyder 3 is necessary to avoid conda update --all to downgrade Spyder 4 to Spyder 3 in order to update Jedi to its latest version (i.e. 0.16.0).

[jjhelmus]

Restricting spyder 3.x to jedi <0.15 will make the anaconda 2019.10 package invalid as that metapackage pins jedi to 0.15.1. That is not something that I can do.

I could add an upper limit of 0.16 but the solver may still prefer spyder 3.x rather than 4.x.

[jjhelmus]

Can the version requirement of spyder 4.0.1 be expanded beyond 1.14.1? Does it work with 0.15.x?

[ccordoba12]

Can the version requirement of spyder 4.0.1 be expanded beyond 1.14.1?

No, it doesn't. We'll try to make our next release (4.1.0) to work with Jedi 0.15.x, but 4.0.1 doesn't work with it, sorry.

[ccordoba12]

Restricting spyder 3.x to jedi <0.15 will make the anaconda 2019.10 package invalid as that metapackage pins jedi to 0.15.1. That is not something that I can do.

This is a real nightmare @jjhelmus. Even if we correctly declare our dependencies, conda update --all messes things horribly in order to update everything at the same time.

I'll check if Spyder 4.0.1 works with 0.15.2 (because it certainly doesn't with 0.15.1) and I'll come back to you with my findings.

[ccordoba12]

conda update --all messes things horribly in order to update everything at the same time.

And it's not just that. I think simply running conda install foo tries to update the other packages in the environment by default. I think conda didn't do that before version 4.7, and I don't understand why it tries to do it now.

[jjhelmus]

And it's not just that. I think simply running conda install foo tries to update the other packages in the environment by default. I think conda didn't do that before version 4.7, and I don't understand why it tries to do it now.

One big change in conda 4.7 which I think is the cause of the current behavior is that by default conda 4.8 first attempts to solve the environment using the packages defined in the current_repodata.json file, falling back to the full collection of packages in repodata.json if this fails. More information on this change and why it was made are discussed in the How We Made Conda Faster in 4.7 blog post.

From what I can tell this behavior results in spyder 3.3.6 being installer rather than 4.0.1. The subset of packages in the defaults channel's current_repodata.json file do not include the necessary packages for a environment with spyder 4.0.1 but do for spyder 3.6.1.

The result is that conda create -n test spyder or conda create -n test spyder --repodata-fn current_repodata.json will install spyder 3.3.6. Forcing the solver to consider all available packages using conda create -n test spyder --repodata-fn repodata.json will result in spyder 4.0.1 being selected.

I do not have a good answer yet on how to address this. The most direct would be a new release of spyder that did not constrain on jedi and parso but I understand that this could require significant development work and sidesteps the issues with conda's solver. I'm looking into what packages are missing from current_repodata which make a spyder 4 environment unsatisfied as a next step.

[jjhelmus]

parso-0.5.2-py_0 is missing from current_repodata.json while leaves conda unable to find a solution when using the requirements for spyder 4.0.0/4.0.1.

[ccordoba12]

parso-0.5.2-py_0 is missing from current_repodata.json while leaves conda unable to find a solution when using the requirements for spyder 4.0.0/4.0.1.

Ok, thanks for finding the cause of this problem @jjhelmus! So, is it possible to add parso-0.5.2-py_0 to current_repodata.json to fix this problem?

[jjhelmus]

I think adding a new build of spyder with the constrained parso requirement to be defaults will cause parso 0.5.2 to be included automatically. I'll try to get a new build out soon to test this but am traveling so it might be a day or two.

[ccordoba12]

I think adding a new build of spyder with the constrained parso requirement to be defaults will cause parso 0.5.2 to be included automatically

A new build of Spyder 4.0.1, you mean? I thought you added a build with the parso requirement already...

[ccordoba12]

@jjhelmus, sorry to bother you, but are there any updates about this? Or do you need us to support Jedi 0.15.2 in Spyder 4.0.1 instead?

[jjhelmus]

I thought you added a build with the parso requirement already...

I hotfixed the existing spyder packages to adjust the parso requirement, no additional build was created.

sorry to bother you, but are there any updates about this?

I've added an an ancillary packages which pulls parso 0.5.2 into current_repodata. From my testing spyder 4.0.1 is now selected over 3.x.

[goanpeca]

Thanks for the update and help with this @jjhelmus

[ccordoba12]

I've added an an ancillary packages which pulls parso 0.5.2 into current_repodata. From my testing spyder 4.0.1 is now selected over 3.x.

Confirmed by our users!! Thanks a lot for your prompt help @jjhelmus!