Working dir changes conflicts with -r include in environment file

[renefritze]

I'm trying to switch to this action from conda-incubator/setup-miniconda@v2 (with use-mamba: true).

I'm using this environment file which includes an requirements files with a relative path. This breaks if I try to use it directly with provision-with-micromamba since it seemingly changes the current working directory to /tmp and during runtime cannot find /tmp/../requirements-ci.txt

Would you consider my setup a valid use case? Is this a bug in this action?

[jonashaag]

I'm not familiar with external files in an environment.yml file but I think we can make it work by not changing directory.

That said, env caching will be broken because it doesn't look at the requirements.txt file.

[renefritze]

Would the env caching not work at all, or would only the packages in the requirements file not be cached?

[jonashaag]

I would be incapable of properly invalidating the cache, thus you'll get the old version of the env after updates to requirements.txt. When envs are restored from cache, no micromamba install/create is executed so nothing will run pip.

[renefritze]

Ok, so my best course of action currently would be to move the pip section out of the environment.yml and mamba install --file it manually? It's not a big deal to me if the packages from the requirements file are not cached.
And after #99 is done I would be able to add the requirements file as an additional environment source? Or does this action only support pure yaml environment configs?

[jonashaag]

By far the best course of action would be to use environment.yml files only. If you're looking for variants (eg. by Python version), maybe you can autogenerate those as well or put some parts into extra-specs of this action?

But yeah using --file should work as well, although I'm not sure this will always reinstall the latest version (the cached env will contain an old version)

[renefritze]

maybe ... put some parts into extra-specs of this action?

That might be a good idea for me, thank you! A previous step could read the requirements file into a step output which I could then use in the extra-specs.

But yeah using --file should work as well, although I'm not sure this will always reinstall the latest version (the cached env will contain an old version)

That would not be an issue for me. The packages in the requirement file all have exact pinned versions anyhow. So this should do as a fallback in case I do not get the other idea to work.

Thanks!

[jonashaag]

Sounds good! Personally I prefer not to make the CI setup too much dependent on GHA so maybe you can also generate a complete environment.yml file and pass that to the action. That way one can also install it locally where extra-specs isn't available. (Actually it is available but not obviously so: micromamba create -f env.yml extra-spec1 extra-spec2 ...)

[renefritze]

Reading the requirements file into a previous step's output and using it in the extra-specs does indeed work as imagined.

[jonashaag]

Please recreate this issue with https://github.com/mamba-org/setup-micromamba if it is still relevant.