`conda env create` with `python=3` receives updates when a `conda env update` with the same input is used

[conda-bot]

The Upstream tests workflow failed on 2023-10-19 07:59 UTC

Full run: https://github.com/conda/conda-libmamba-solver/actions/runs/6571208348

(This post will be updated if another test fails, as long as this issue remains open.)

[jaimergp]

Observed and discussed in https://github.com/conda/conda-libmamba-solver/pull/323#issuecomment-1770405082. Copying here for reference:

tests/conda_env/test_cli.py::test_update_env_no_action_json_output errors are legit but caused by a unique situation. This is the gist:

• Having an env.yml file with python=3, pip and pip: click, we should be able to create it with conda env create.
• A subsequent call to conda env update should do nothing because we just installed everything.

Makes sense, but this is what we observe in this error:

1. conda env create creates an environment with python=3.11 and pip=23.3. It prioritizes having a greater pip version than a Python one, possibly because it comes earlier in the sorting (i beats y).
2. However, conda env update imposes python=3 again (not just python!), which is interpreted as "update python". This time, the solver tries to satisfy the petition more aggressively, even allowing a pip downgrade this time, because the alternative is to say "we are ok".

We didn't see this error earlier because the packaging situation is unique: defaults has Python 3.12 now, but only pip 23.2 is available for that version. The most recent 23.3 is only available for Python 3.11. I'm assuming once the new pip is available for 3.12 this will pass, but the currently observed behavior is a bit surprising and might deserve a fix.

---

Note that changing the environment.yml file to the following makes everything pass as expected:

ENVIRONMENT_PYTHON_PIP_CLICK = f"""
name: {TEST_ENV_NAME_1}
dependencies:
- - python=3
+ - python
  - pip
  - pip:
    - click
channels:
  - defaults
"""

---

This alternative change in solver.py also makes things pass. MatchSpec.merge sorts everything by str, and we used to keep that:

        self.specs_to_add = IndexedSet(MatchSpec.merge(s for s in fixed_specs))

However, if we prio Python, it passes:

        resorted_specs = []
        for spec in MatchSpec.merge(s for s in fixed_specs):
            if spec.name == "python":
                resorted_specs.insert(0, spec)
            else:
                resorted_specs.append(spec)
        self.specs_to_add = IndexedSet(resorted_specs)

[jezdez]

I'm not sure if we should prio Python, I concur it might be an edge case, of the packages versions not being available as expected

[github-actions[bot]]

Hi there, thank you for your contribution!

This issue has been automatically marked as stale because it has not had recent activity. It will be closed automatically if no further activity occurs.

If you would like this issue to remain open please:

1. Verify that you can still reproduce the issue at hand
2. Comment that the issue is still reproducible and include: - What OS and version you reproduced the issue on - What steps you followed to reproduce the issue

NOTE: If this issue was closed prematurely, please leave a comment.

Thanks!