Issue with package specification in create-args

[sblauth]

I have a problem / unexpected behavior when using create-args and specifying a package restriction. E.g., if I use the following code in my "old" setting:

- name: Install micromamba
      uses: mamba-org/provision-with-micromamba@main
      with:
        environment-file: .github/micromamba/testenv.yml
        extra-specs: |
          gmsh">=4.8"

to specify that gmsh with version <= 4.8 has to be used.

When I switch to setup-micromamba, I use the following analogous code

- name: Install micromamba
      uses: mamba-org/setup-micromamba@v1
      with:
        environment-file: .github/micromamba/testenv.yml
        create-args: >-
          gmsh">=4.8"

but this raises an error. If I drop the quotation marks and use the code

- name: Install micromamba
      uses: mamba-org/setup-micromamba@v1
      with:
        environment-file: .github/micromamba/testenv.yml
        create-args: >-
          gmsh>=4.8

everything works fine. I think this issue should at least be documented somewhere, or the usual conda syntax (with quotation marks) should work here.

[jonashaag]

I don't think using quotes like that is supported by Conda, Mamba, or Micromamba. Do you have an example of using this quoting style that works?

[sblauth]

Sure, I originally found this on stackoverflow: https://stackoverflow.com/questions/38411942/anaconda-conda-install-a-specific-package-version/58630489#58630489

And I use it all the time in the workflows for my package cashocs, see, e.g., https://github.com/sblauth/cashocs/blob/main/.github/workflows/tests_serial.yml

I've also tried this locally with mamba 1.4.2 and mamba search Running mamba search -c conda-forge numpy>=1.24.4 did not return anything, whereas the version with quotes mamba search -c conda-forge numpy">=1.24.4" returns the desired list of packages.

[jonashaag]

That's curious, I don't think we will add support for that though.

The effect you are seeing with search is likely to be shell quoting: without quotes > means that the output of the command is redirect to the file named by whatever is written after the >.

[sblauth]

Yes, that makes sense. Okay, then people with the same problem as me can take a look at this issue and find a "workaround". This issue can then be closed imo.