Still having errors with 32-bit miniconda setups

[ktbarrett]

From here. I am specifying miniconda-version and still get errors. The following line is to blame (I think, I don't know JS), it seems that it should check if miniconda-version is not set and architecture != x64, based on the error message. https://github.com/conda-incubator/setup-miniconda/blob/35d1405e78aa3f784fe3ce9a2eb378d5eeb62169/src/input.ts#L61-L63

[chrisjbillington]

Me too, though I am specifying miniconda-version as "latest". Is the intention that one needs to be specific and not just specify "latest"?

      - name: Install Miniconda
        uses: conda-incubator/setup-miniconda@v2
        with:
          auto-update-conda: true
          python-version: ${{ matrix.python }}
          architecture: ${{ matrix.arch }}
          miniconda-version: "latest"

Run conda-incubator/setup-miniconda@v2
  with:
    auto-update-conda: true
    python-version: 3.7
    architecture: x86
    miniconda-version: latest
    activate-environment: test
    auto-activate-base: true
    remove-profiles: true
    clean-patched-environment-file: true
  env:
    PACKAGE_NAME: desktop-app
    SCM_LOCAL_SCHEME: no-local-version
    ANACONDA_USER: labscript-suite
    PURE: false
    NOARCH: false
    pythonLocation: C:\hostedtoolcache\windows\Python\3.7.9\x86
    CONDA_BUILD_ARGS: 
Gathering Inputs...
  Error: 'architecture: x86' requires "miniconda-version"
Error: 1 errors found in action inputs

[ktbarrett]

See #147. It seems they are not interested in supporting specifying "latest" since the latest is quite old.

[chrisjbillington]

Thanks for the info @ktbarrett.

Is there a way to say "use the most recent version number"? That's what I actually want. I mistakenly thought that's what "latest" meant, and fair enough to not support it if what they call "latest" is actually super old.

But having to carry around a specific version number in my workflow files that I have to update occasionally defeats some of the purpose of automating this stuff with workflows in the first place, so an "actually latest" option would be good! Then again if "latest", though seldom-updated is actually the most tested and stable release of conda tools then I'm totally happy to stick with it. I don't need the actual latest, I just want something well-tested that I don't have to manually bump the version of ever.

I've got a whole bunch of workflows in different repos building conda packages, and the busywork of making the same one line change in all them of them sometimes makes me question why I'm using github actions at all compared to building locally like I used to do.

[ktbarrett]

have to update occasionally

Anaconda does not intend to ever release another 32-bit build, see the second paragraph of the 4.5.12 release notes. So "4.5.12" is and will always be "latest".

[chrisjbillington]

I don't care about 32-bit Linux, I'm not building for that. My error is on Windows. If they're still releasing occasional 32 bit builds for Windows and calling them "latest" then I'm happy :)

And if they stop releasing 32-bit builds for Windows then I'll just stop doing so as well - I don't need to build my packages for a platform on which conda doesn't exist!

[ktbarrett]

Ah, I did not notice at first you were talking about Windows. I had a user report on error using 32 bit Anaconda on a RHEL7 machine, so I had to oblige.

[bilderbuchi]

The latest Windows x86 version seems to be https://repo.anaconda.com/miniconda/Miniconda3-py39_4.10.3-Windows-x86.exe from last month, so I don't think the "too old" argument is valid in that case.

[chrisjbillington]

Should be fixed by #189

[goanpeca]

Thanks!

[ktbarrett]

@chrisjbillington Have you seen #168? I tried a while ago with the same fix, but had trouble getting a test to actually work.

[chrisjbillington]

@ktbarrett I must have seen it since I've commented there, but totally forgot about it when I filed #189!

There seem to be two separate issues - one is supporting some very old versions of miniconda (which happen to be 32-bit), and the other is this bug preventing the use of perfectly recent 32-bit miniconda builds such as

Miniconda3-latest-Windows-x86.exe	55.3M	2021-07-21 11:05:08	a082be7ef6dd4f14b974dab2d78c5693

It would be nice to unbreak setup-miniconda for 32-bit Windows in the meantime even if the other 32-bit builds require more work to support!

[jaimergp]

Do we have a timestamp that we can use to separate "very old, does not work for now" from "recent x86 that should work without problems"? Maybe there's some metadata in the .exe we can query to double check in the meantime.

[chrisjbillington]

The version number (available in the filenames) would presumably be enough to know which are too old - one would have to do some research to figure out which is the minimum version that doesn't have any of the problems discussed in #168.

For the "latest" filenames, one could use md5sums to match a "latest" .exe/.sh to one with a version number in its filename in the repo, and therefore figure out what version it is.

For example the current 'Miniconda3-latest-Windows-x86.exe' has the same md5sum as 'Miniconda3-py39_4.10.3-Windows-x86.exe' and is therefore miniconda3 4.10.3.

Whereas the current 'Miniconda3-latest-Linux-x86.sh' has the same md5sum as 'Miniconda3-4.5.12-Linux-x86.sh', and is therefore miniconda3 4.5.12.

[jaimergp]

It's 4.6, I believe. Added more details in the linked PR.

I think we are not supporting version: latest together with non-x64 archs so we don't need to check for hashes.

[chrisjbillington]

Supporting version: latest for Windows x86 is what I was hoping #189 would achieve. Is there a reason not to support it other than not being able to easily get the version number to check it? Prior to the changes leading to this bug report, it used to work fine.

Perhaps the code could exempt Windows, specifically, from rejection if "latest" is used with non-64-bit arch? Since the Windows x86 "latest" build is maintained and unproblematic.

I'm trying to avoid having to maintain explicit version numbers in workflows so that they don't need as much maintenance, so being able to use "latest" is highly desirable.

I don't know a lick of javascript, otherwise I'd be writing a hash-matching code snippet instead of this comment.

[jaimergp]

Fair enough, that's a case worth pursuing. I'll see if I can come up with something later today. My JS/TS is also null, but I'll throw stuff at the IDE and see what sticks :D

[jaimergp]

Would it be ok if I commit to your PR to provide this workaround too and add the relevant tests?

[chrisjbillington]

Would it be ok if I commit to your PR to provide this workaround too and add the relevant tests?

Absolutely, go ahead! I think I've already granted that permission for the PR, let me know if I haven't.