test noarch bld

[ngam]

Checklist

• [x] Used a personal fork of the feedstock to propose changes
• [x] Bumped the build number (if the version is unchanged)
• [x] Reset the build number to 0 (if the version changed)
• [x] Re-rendered with the latest conda-smithy (Use the phrase code>@<space/conda-forge-admin, please rerender in a comment in this PR for automated rerendering)
• [x] Ensured the license file is being packaged.

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[ngam]

@conda-forge-admin , please rerender

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipe) and found some lint.

Here's what I've got...

For recipe:

• noarch packages can't have selectors. If the selectors are necessary, please remove noarch: python.

[ngam]

@conda-forge-admin , please rerender

[conda-forge-linter]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipe) and found it was in an excellent condition.

[ngam]

@conda-forge-admin , please rerender

[github-actions[bot]]

Hi! This is the friendly automated conda-forge-webservice. I tried to rerender for you, but it looks like there was nothing to do.

[ngam]

@conda-forge-admin , please rerender

[github-actions[bot]]

Hi! This is the friendly automated conda-forge-webservice. I tried to rerender for you, but it looks like there was nothing to do.

[ngam]

@conda-forge-admin, please rerender

[ngam]

@hjoliver @oliver-sanders

converted this into noarch build for convenience and conserving resources. This makes it work with aarch64, etc.

build looks fine and it seems this could be merged. I will do additional testing offline to make sure all works as expected (building locally). Let me know if you've got any questions/comments. Thanks!

# To have conda build upload to anaconda.org automatically, use
# conda config --set anaconda_upload yes
anaconda upload \
    /home/conda/feedstock_root/build_artifacts/noarch/cylc-flow-base-8.0b3-pyh6c4a22f_1.tar.bz2 \
    /home/conda/feedstock_root/build_artifacts/noarch/cylc-flow-8.0b3-pyhad50eba_1.tar.bz2
anaconda_upload is not set.  Not uploading wheels: []

INFO :: The inputs making up the hashes for the built packages are as follows:
{
  "cylc-flow-8.0b3-pyhad50eba_1": {
    "recipe": {
      "channel_targets": "conda-forge main",
      "graphviz": "2.47",
      "python": "3.9.* *_cpython"
    }
  },
  "cylc-flow-base-8.0b3-pyh6c4a22f_1": {
    "recipe": {
      "channel_targets": "conda-forge main",
      "python": "3.9.* *_cpython"
    }
  }
}

[ngam]

closes #30

[ngam]

Note, from my prelim testing, this is fine but won't necessarily resolve on some OS. The problem is in the wildly restrictive dependencies in the upstream repo. Will likely need to relax those if a noarch build to be legitimately useful... I built locally with all numbered conditions taken out (so relying on conda-forge resolve) and the build was smooth and the testing so far fine. So perhaps we could do without the restrictive deps? That's up to the upstream devs though...

[oliver-sanders]

@ngam

Thanks for your interest!

converted this into noarch build for convenience and conserving resources. This makes it work with aarch64, etc.

The list of criterion for noarch: python packages includes "No skips except for python version".

Cylc Flow is unix only and will not work on other platforms, hence the skip presently in the recipe. As a result of this Cylc Flow does not qualify for noarch.

The problem is in the wildly restrictive dependencies in the upstream repo

We've yet to encounter such issues, if you could tell us the dependencies that are causing you issues on your system we may be able to look into it. I think aarch support is lagging with a few libraries, if we know which ones are causing the pain we may be able to push support out further for them.

[ngam]

Cylc Flow is unix only and will not work on other platforms, hence the skip presently in the recipe. As a result of this Cylc Flow does not qualify for noarch.

Ah! Makes sense now. Okay, let's close this pr and focus on explicit support for osx-arm64 and linux-aarch64 (could potentially also add ppc). I will follow up on the dependencies so that we can narrow it.

[oliver-sanders]

I'm dropping a question in to the Conda Forge Gitter in the hope they can advise a better way forward. We should be noarch: python, just in a way that somehow excludes Windows.

[ngam]

I think they might say you'd need to specify the other ones explicitly. I can help you implement all unix-like platforms once we see what's up with the deps. We may need some tweaking for the aarch64/arm64 though as not everything is supported

[ngam]

I have access to linux_aarch64 (via multipass.run) and so I can test that pretty easily on my m1 mac

[oliver-sanders]

Apparently it's not an issue for a noarch: python package to have dependencies which don't resolve on all platforms. There are some virtual packages called __unix and __win which could do the trick.

[oliver-sanders]

https://docs.conda.io/projects/conda/en/master/user-guide/tasks/manage-virtual.html?highlight=__unix#managing-virtual-packages