--force-reinstall old conda to ensure it's working before we try to install conda packages #920
Conversation
an old conda bug causes RemoveError: requests is a dependency of conda when installing other packages upgrading conda itself avoids this bug. It's unclear what the true minimum version is to fix this, but the important thing is that it will be upgraded if it's still the version in 0.2.0 (4.10), so pick the version from today which we know works
if conda upgrade conda is broken, we are in trouble this is required to avoid the RemoveError
|
It appears to be a little tricky to upgrade conda itself when the env is considered broken like this. Working on it. |
not deprecated --force
|
If we don't want to bump versions, it appears the fix is specifically: which should ensure that conda itself is in a consistent state (and should not upgrade it). We could do that as a separate, unconditional 'ensure conda is okay' step before installing anything, but I believe using We could also try to restrict 'needs force' to a version constraint, but I have no idea what that constraint would be. |
I think its great if we avoid introducing that precautionary, as it makes the situations that can arise grow and its harder to ensure function in all situations. For the same reasons, I'm happy about seeing more stringent requirements on the conda/mamba versions. |
|
I think maybe it makes sense to unconditionally force-reinstall conda/mamba to ensure it's always consistent, followed by the upgrade steps. |
minrk
force-pushed
the
upgrade-mamba-conda
branch
2 times, most recently
from
ec0bcb5 to
c032291
Compare
makes it more likely that subsequent conda installs will succeed - fix indentation on the upgrade steps so they aren't run every iteration - no longer need to bump required versions
minrk
force-pushed
the
upgrade-mamba-conda
branch
from
c032291 to
ee23e04
Compare
minrk
changed the title
| USER_ENV_PREFIX, list(to_reinstall), force_reinstall=True | ||
| ) | ||
|
|
||
| cf_pkgs_to_upgrade = list(set(to_upgrade) & {"conda", "mamba"}) |
There was a problem hiding this comment.
These lines are unchanged, but they are dedented because they should have always been run after the for loop, not on each iteration. Results should be unchanged, it was just a few unnecessary calls to conda install:
# first 'conda' iteration
conda install conda
# second 'mamba' iteration
conda install conda mamba
# third 'pip' iteration
conda install conda mamba
pip install --upgrade pipwhen it should have just been the last two calls.
|
Struggling to get the right behavior here to match elaborate test expectations. It seems It really seems the 'reinstall if needed' is what we want, but I can't seem to figure out 'if needed'. |
avoids upgrade on older versions
|
I searched on |
| # avoids issues with RemoveError: 'requests' is a dependency of conda | ||
| # only do this for 'old' conda versions known to have a problem | ||
| # we don't know how old, but we know 4.10 is affected and 23.1 is not | ||
| if not is_fresh_install and V(package_versions.get("conda", "0")) < V("23.1"): |
There was a problem hiding this comment.
I don't really like what I ended up doing here, but I bracketed the force reinstall on a version older than what's going to be in 1.0, with the hope that we actually remove this step when we drop support for upgrading from earlier than 1.0.
I think you need pretty old conda to get here, but that's what we have in 0.2. It really is a special-case to handle:
- quite old conda
- inconsistent environment in conda's own dependencies (caused by our own
pip install --upgradecommands)
but this is what you'll get if you start with tljh 0.2 and haven't upgraded conda, so we should handle it. I think it is appropriate to treat it specially, as if users have broken their own envs such that conda itself doesn't work, I think it's appropriate for us to not handle that and require users to fix their conda (or delete their user env to start fresh) before upgrading. But since we are creating a broken environment, we need to handle it, at least for the very specific case of upgrading from a previous tljh known to have this issue.
There was a problem hiding this comment.
LGTM, go for merge?
THANK YOU FOR WORKING THIS @minrk !!!!!!!!!!
|
phew everything's passing and test expectations are unchanged. One thing that might help these things (or might not, honestly, since it creates an extra env to manage) is to make the root conda install a separate environment from the user env:
Then conda/mamba themselves won't actually interact with user packages. This is where the |
|
all set from my side, yes |
minrk
changed the title
|
I'd love to see tljh 1.0.0 installations - either fresh installs or upgrades, arrive to an even more solid baseline that we can count on going onwards. But that would be a separate discussion!
Yikes, as a maintainer I just feel that I've caught up with the understanding of:
I think the problems solved should be major to justify an additional environment because of the complexity of even just understanding the purpose of each, and documenting that, etc. |
|
btw, I'm still seeing this on https://github.com/jupyterhub/the-littlest-jupyterhub/actions/runs/6357501669/job/17268703149#step:5:157 from #942 (which is based on latest main) |
an old conda bug causes RemoveError: requests is a dependency of conda when installing other packages (closes #918).
Upgrading conda itself first avoids this bug (we _may_ want `--force` here, which some folks have seen required when conda itself is messed up, but let's avoid it for now). So we know that the version in 0.2.0 (4.10) is not actually new enough to work. It's unclear what the true minimum version is to fix this, but the important thing is that it will be upgraded if it's still the version in 0.2.0 (4.10), so pick the versions from today which we know works, and will be the version upgraded-to if an 0.2 install has yet to update conda.conda install --force-reinstall condais the fix for this, becauseconda install condawill fail to upgrade if we're in this situation. We could make it conditional on old condas, as I don't think this is likely to come up with more recent versions, but it should be safe in general to run this command.