Replace all the tests with something super simple

[liamhuber]

To try to track down what is going wrong upstream with the placements of conda env files. Trying to make progress on #634 .

[github-actions]

👈 Launch a binder notebook on branch pyiron/pyiron_workflow/simple_ci

[liamhuber]

Ok, beautiful, this works fine:

Run conda-incubator/setup-miniconda@v3
  with:
    python-version: 3.12
    channels: conda-forge
    conda-remove-defaults: true
    channel-priority: strict
    activate-environment: my-env
    environment-file: ./environment.yml
    auto-activate-base: true
    auto-update-conda: false
    remove-profiles: true
    conda-solver: libmamba
    clean-patched-environment-file: true
    run-post: true
  env:
    PYTHONPATH: /home/runner/work/pyiron_workflow/pyiron_workflow/tests/unit:/home/runner/work/pyiron_workflow/pyiron_workflow/tests/static:/home/runner/work/pyiron_workflow/pyiron_workflow/tests/integration:/home/runner/work/pyiron_workflow/pyiron_workflow/tests/benchmark:/home/runner/work/pyiron_workflow/pyiron_workflow/tests:
    WRITE_ENVIRONMENT_OUTPUT_ENV_FILE: ./environment.yml

Now let's turn on miniforge and see what happens

[liamhuber]

That didn't break anything in the tests -- all 196 ran ok -- but the job is anyhow hanging for a long time afterwards.

[liamhuber]

I had an upstream typo in deactivating the defaults channel, but other than that, I can see that the conda info are extremely similar, except env name and the path for the location of the env is /home/runner/work/pyiron_workflow/pyiron_workflow/cached-miniforge/my-env in the failed pyiron/actions usage, and simply my-env (/home/runner/miniconda3/envs/my-env) for the name (location) in my direct usage.

When I look at the respective invocations of setup-miniconda, the difference is in activate-environment: my-env vs activate-environment: cached-miniforge/my-env. Let's try to narrow down if this is the cause by modifying the working version to have this path-like env name and try to induce a failure.

[liamhuber]

Perfect! Yes, then it looks like the trouble is that I'm providing a path-like env name.

This is interesting, because setup-miniconda explicitly claims to handle path-like values. Again though, since that code hasn't been touched in four months and the problem is only five days old, maybe it still lies somewhere else.

I also find it further strange, because the failed mamba example also started 5 days ago, but there the activate-environment: anaconda-client-env isn't path-like at all. Maybe five days ago there was some larger update that is malfunctioning in multiple independent ways?

[liamhuber]

Both de-pathing the environment name (env-path: cached-miniforge_my-env in the script using pyiron/actions cached-miniforge) and localizing the provided path (activate-environment: ./cached-miniforge/my-env) worked fine.

Interestingly, in the latter case, the conda info is still the big full path:

    active environment : /home/runner/work/pyiron_workflow/pyiron_workflow/cached-miniforge/my-env
    active env location : /home/runner/work/pyiron_workflow/pyiron_workflow/cached-miniforge/my-env

This is the exact path when we didn't localize and failed, so conda info is sanitizing the path sensibly, but I guess some other step in the process is not. That is so bizarre that I'm going to revert the ./ one more time just to convince myself I can re-break it.

[liamhuber]

Ok, this informs me how to modify pyiron/actions#145 to get around this problem. However, I still have no idea about the docs job, and something still changed in a negative way somewhere upstream. So for the moment let's sit and wait.

[liamhuber]

Alright, using default parameters works so pyiron/actions#145 is fixing half of #634 (I still don't know what's going on with building the docs)