Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Be extra rigorous about using conda-forge #127

Closed
liamhuber opened this issue Aug 26, 2024 · 8 comments
Closed

Be extra rigorous about using conda-forge #127

liamhuber opened this issue Aug 26, 2024 · 8 comments
Assignees
Labels
enhancement New feature or request

Comments

@liamhuber
Copy link
Member

Due to anaconda license terms. pyiron/actions/cached-miniforge uses miniforge and strictly uses the conda-forge channel. I'll anyhow update the defaults for these args so we are explicitly requesting the miniforge-channels and miiniforge-channel-priority from our end rather than relying on the setup-miniconda defaults being favourable (although it seems unlikely they'll change these).

@liamhuber liamhuber added the enhancement New feature or request label Aug 26, 2024
@liamhuber liamhuber self-assigned this Aug 26, 2024
@liamhuber
Copy link
Member Author

This is a non-issue, because we already expose the underlying arguments (in case you want to set them yourself), we already override conda-incubator/setup-miniconda kwargs with our own kwargs in cached-miniconda, and these are exactly the "safe" ones that are both what we want and the current setup-miniconda defaults.

@liamhuber
Copy link
Member Author

Nope, it looks like the mamba update call still eventually falls back to include defaults!

Screen Shot 2024-08-26 at 10 44 31

@liamhuber liamhuber reopened this Aug 26, 2024
@liamhuber
Copy link
Member Author

Hmm, except the latest cached-miniforge never explicitly calls mamba update -- now it's always setup-miniconda, so there's a possibility this is actually an upstream issue with setup-miniconda not following through...

@liamhuber
Copy link
Member Author

liamhuber commented Aug 26, 2024

Indeed, this is a known issue on conda-incubator/setup-miniconda and even a known gotcha on conda/conda.

One solution is to specify nodefaults right in your env-file....

channels:
- conda-forge
- nodefaults
dependencies:
...

But this is still sub-optimal IMO.

@jan-janssen
Copy link
Member

An alternative option, is to create your own .condarc using:

echo -e "auto_update_conda: False\nauto_activate_base: True\nnotify_outdated_conda: False\nchangeps1: False\npkgs_dirs:\n  - /home/runner/conda_pkgs_dir\nchannels:\n  - conda-forge\nalways_yes: True\nsolver: libmamba" > .condarc

then you can include it in the action using:

condarc-file: .condarc

I tested this for the notebooks test in pyiron/pyiron_atomistics#1545

@liamhuber
Copy link
Member Author

👍 I find this preferable to having to specify channels: nodefaults in each env file. It's still ugly compared to specifying the channel right in the setup-miniconda action and actually having it read that, so I'm working on a patch for the root action there.

@liamhuber
Copy link
Member Author

The key thing in your solution is channels:\n - conda-forge, as then the channels field is not initially empty and thus conda doesn't pre-populate it with defaults. It's possible you can then trim down the rest of the RC file and have setup-miniconda populate the rest, but I don't know what the interaction is between a provided RC file and the action arguments.

@liamhuber
Copy link
Member Author

I opened a PR to fix it upstream.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants