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

setup-micromamba rewrite specification #114

Closed
jonashaag opened this issue Jan 17, 2023 · 16 comments · Fixed by #122
Closed

setup-micromamba rewrite specification #114

jonashaag opened this issue Jan 17, 2023 · 16 comments · Fixed by #122

Comments

@jonashaag
Copy link
Collaborator

jonashaag commented Jan 17, 2023

We're going to release a new version of provision-with-micromamba:

  • With a new name, setup-micromamba (other suggestions welcome; the action's main task is to set up a Conda environment using Micromamba)
  • Rewritten in TypeScript
  • Using semantic versioning

We will add a upgrade hint to this repo and maybe add a warning in the GHA output.

Use cases

We'll remove some of the options of provision-with-micromamba, see here for discussion #103.

Here we'll collect some use cases that we want to support. Feel free to make more suggestions.

Env from environment.yml

Options:

  • Path to environment.yml (no implicit default of ./environment.yml like in provision-with-micromamba)
  • Optional path to .condarc (implicit default to ~/.condarc)

Env from environment.yml with extra specs

Like above, but with an optional extra-specs: x y z option. This is runs

micromamba create -f environment.yml x y z

Env without environment.yml

For tiny CI setups, options:

  • Extra specs
  • environment-name to substitute the missing name: in environment.yml
  • Channels from .condarc

Installing Micromamba only

  • Provide create-env: false to skip micromamba create and just download + setup Micromamba.

Creating an empty env

Not sure if we should support this.

Convenience options

Implicit conda-forge

If using only extra specs and no .condarc is given, default to conda-forge? Although this reuqires that we check .condarc.

.condarc as string

Allow syntax like the following?

with:
  condarc: |
    channels:
      - x

Although this is also possible simply by using cat in a preceding step.

Proposal

Derived from the use cases, we offer the following options:

  • condarc-file: Path to a .condarc file to consider, defaults to ~/.condarc.
  • environment-file: Path to environment file, no default.
  • environment-name: Override name: in environment.yml and set name if not passing environment.yml.
  • extra-specs: String with extra specs to pass to micromamba create.
  • create-args: List of strings that are passed to micromamba create.
  • create-env: false to skip micromamba create.
  • micromamba-version, cache-*, log-level, installer-url, post-deinit.
@pavelzw
Copy link
Member

pavelzw commented Jan 17, 2023

What will happen when you don't supply anything to environment-file?
Will an env still be created? What will the name be? base?

I think it makes sense to allow the user just to install micromamba without any environment creation steps, maybe by setting create-env: false. One fictional use case would be that the user wants to make sure that a certain package is pushed to a repository and just wants to do micromamba search <package>. This doesn't need an environment.

@pavelzw
Copy link
Member

pavelzw commented Jan 17, 2023

Some thoughts on log-level: GitHub Actions support different log-levels natively. See Workflow commands for GitHub Actions / Setting a debug message.

The debug mode is active when ACTIONS_SETUP_DEBUG=true. You can print debug messages by executing echo "::debug::This is a debug message" (or using the @actions/core debug method). These messages only get printed when ACTIONS_SETUP_DEBUG=true. This can be achieved by setting it in the workflow itself or by enabling debug logging when rerunning a workflow.

Since we probably cannot add ::debug:: in between micromamba logs, I think it would be a good idea to set the log-level to debug when ACTIONS_SETUP_DEBUG=true automatically. Then you do not need to create a separate commit to do this when encountering an error.

See here for an example with debug turned off and here for an example with debug logging.

@pavelzw
Copy link
Member

pavelzw commented Jan 17, 2023

.condarc as string

Allow syntax like the following?

Is this possible in Workflow files?

@pavelzw
Copy link
Member

pavelzw commented Jan 17, 2023

Also, we should use dependabot to upgrade the version of @actions/core. I see far too many actions that still use old versions of this package resulting in node deprecation warnings as well as set-output deprecation warnings. This is the default anyway in actions/typescript-action.

@jonashaag
Copy link
Collaborator Author

What will happen when you don't supply anything to environment-file?
Will an env still be created? What will the name be? base?

Good point, will add environment-name back.

I think it makes sense to allow the user just to install micromamba without any environment creation steps, maybe by setting create-env: false. One fictional use case would be that the user wants to make sure that a certain package is pushed to a repository and just wants to do micromamba search <package>. This doesn't need an environment.

I'm not quite sure about this. I agree that you might want an empty environment but if you want micromamba only you can use micro.mamba.pm/install.sh.

I think it would be a good idea to set the log-level to debug when ACTIONS_SETUP_DEBUG=true automatically

Agreed!

.condarc as string

Allow syntax like the following?

Is this possible in Workflow files?

Yes but the stuff after | is just plain text; no YAML parsing involved.

This is the default anyway in actions/typescript-action.

Perfect!

@pavelzw
Copy link
Member

pavelzw commented Jan 17, 2023

I'm not quite sure about this. I agree that you might want an empty environment but if you want micromamba only you can use micro.mamba.pm/install.sh.

pnpm/action-setup is kind of similar to our use case. They also provide this functionality.

@jonashaag
Copy link
Collaborator Author

OK added it!

@pavelzw
Copy link
Member

pavelzw commented Jan 21, 2023

I think adding some sort of environment information, i.e. which exact package versions were installed, to the step output (maybe even optional to the job summary?) might also be helpful.

@jonashaag
Copy link
Collaborator Author

It’s already there in the „Environment Info“ output, or are you looking for something else?

@pavelzw
Copy link
Member

pavelzw commented Jan 21, 2023

I meant the GITHUB_OUTPUT for a specific step such that you can you can use this output in future Workflow steps, see here.

@pavelzw
Copy link
Member

pavelzw commented Jan 28, 2023

Maybe adding something like init-shell: ['zsh', 'bash'] would also be a nice option to make it easier to manage stateful selfhosted runners.

@pavelzw
Copy link
Member

pavelzw commented Feb 16, 2023

If it is possible to add micromamba as a shell option in GitHub (see ADR 0277), we should explore this option. Having something like

- run: pytest ...
  shell: micromamba

would be a nice to have.

@zacharyburnett
Copy link

This would be great for me, as I have recently had issues running provision-with-micromamba on a self-hosted runner, as it overwrites and adds to the .condarc file every time.

@jonashaag
Copy link
Collaborator Author

This would be great for me, as I have recently had issues running provision-with-micromamba on a self-hosted runner, as it overwrites and adds to the .condarc file every time.

Note this: https://github.com/mamba-org/provision-with-micromamba#post-deinit

@mikemhenry
Copy link

This proposal looks great, I use this action extensively (I've been switching to this action from the mamba/conda ones whenever I get the chance) and the proposal covers all of my use cases.

@pavelzw
Copy link
Member

pavelzw commented Apr 26, 2023

The first release of setup-micromamba is out, feel free to check it out 🎉

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

Successfully merging a pull request may close this issue.

4 participants