search

conda-forge / spyder-feedstock

A conda-smithy repository for spyder.
BSD 3-Clause "New" or "Revised" License
1 stars 17 forks source link

PR: Update psutil #74

Closed goanpeca closed 4 years ago

goanpeca commented 4 years ago

Checklist

conda-forge-linter commented 4 years ago

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 commented 4 years ago

@ccordoba12 ready!

ccordoba12 commented 4 years ago

Pinging @jjhelmus about this one. This is a new build to fix a critical issue with our Kite integration with older psutil versions.

jjhelmus commented 4 years ago

I can make modification to defaults to add this change but I need some additional information on how this is expect to work.

The older builds of spyder are still available on conda-forge and will be installed without this new dependency information (and the parso constraint in #73) if those produce a more optimal solution. Should these older builds be removed or hotfixed with the new dependency information?

Do these new dependency constrains apply to older versions of spyder?

goanpeca commented 4 years ago

The older builds of spyder are still available on conda-forge and will be installed without this new dependency information (and the parso constraint in #73) if those produce a more optimal solution. Should these older builds be removed or hotfixed with the new dependency information?

The older builds can lead to envs where the versions are not ok but could be easily updated by the user (like the psutil case)

Do these new dependency constrains apply to older versions of spyder?

We should have applied this to all the 4.x versions of Spyder out there, so it is probably our bad for not doing it on time.

shoudl they be removed or hotfixed?

Not sure, what do you recommend?

jjhelmus commented 4 years ago

Not sure, what do you recommend?

For defaults we do not remove packages except in extreme cases so I was planning on hotfixing the existing packages to add the parso requirement and place minimum version of the psutil requirement.

conda-forge has a tradition of moving packages with incorrect dependency information to the broken label so that users do install them but they are still available for historic archival reasons. This could be done here. Alternatively, the dependency information in conda-forge can be hotfixed although the process is a bit more involved.

ccordoba12 commented 4 years ago

For defaults we do not remove packages except in extreme cases so I was planning on hotfixing the existing packages to add the parso requirement and place minimum version of the psutil requirement

I agree this is the best solution for defaults, i.e. both 4.0.0 and 4.0.1 should have parso 0.5.2 and psutil >=5.3 among their dependencies.

This could be done here

We don't have permissions to change labels in the conda-forge channel. But I think you do, so if you could help us with that, we'd really appreciate it (I think moving 4.0.1 builds 0 and 1 to broken should be enough).

goanpeca commented 4 years ago

For defaults we do not remove packages except in extreme cases so I was planning on hotfixing the existing packages to add the parso requirement and place minimum version of the psutil requirement.

Ok, then hotfix is the way. Thanks a lot!

conda-forge has a tradition of moving packages with incorrect dependency information to the broken label so that users do install them but they are still available for historic archival reasons. This could be done here. Alternatively, the dependency information in conda-forge can be hotfixed although the process is a bit more involved.

Yes I have seen, will ask the previous versions to be moved then to the broken label.

@ccordoba12 do you agree with this?

ccordoba12 commented 4 years ago

do you agree with this?

Yes. I think it's better to avoid conda picking up wrong versions when solving dependencies.

jjhelmus commented 4 years ago

I've created conda-forge/cf-mark-broken#8 which will move the build 0 and 1 packages in conda-forge to the broken label once merged.

I also hotfixed the dependency information for the spyder 4.0.0 and 4.0.1 packages in defaults in AnacondaRecipes/repodata-hotfixes#69. These changes are live in defaults.

Sorry for being a bit delayed in responding to this issue. The distribution team is preparing releases of Miniconda and Anaconda and I am the release manager for both. This role has been taking a lot of my time the last few days.

goanpeca commented 4 years ago

Sorry for being a bit delayed in responding to this issue. The distribution team is preparing releases of Miniconda and Anaconda and I am the release manager for both. This role has been taking a lot of my time the last few days.

No worries, we know how this goes :-)

Thanks so much for your help @jjhelmus !

ccordoba12 commented 4 years ago

Sorry for being a bit delayed in responding to this issue. The distribution team is preparing releases of Miniconda and Anaconda and I am the release manager for both

When the new Anaconda release is planned for? We have an important release in the making with lots of bugfixes, and it's almost ready, so we'd really like for Anaconda to include it in its next version.

jjhelmus commented 4 years ago

When the new Anaconda release is planned for?

The first RC went to QA yesterday with a goal of releasing sometime next week (might slip to the following week).