This wasn't necessary for pyiron_ontology (which uses pyproject.toml) nor for pyiron_workflow (still using setup.py), and I don't know why it was needed here. Since the base PR wound up getting closed, I'm going to revert these to their simpler state. I thought maybe these had versioneer somewhere in their dependency tree and pyiron_base didn't, but we're printing the conda list now and I can see that's not the case. Without further data I'm left to conclude this is an issue with pyiron_base being too picky and not with pyiron/actions being too lazy. For the sake of speed, we won't pip install versioneer when we don't need to. Ahhh, no, better, let's feature-flag it.
Ok, it's in cached-miniforge so the idea won't get lost, but I'm not going to bother exposing the input in the reusable workflows unless we need it.
Adjusting the CI interface to get stuff running on pyiron base
Based on feedback in https://github.com/pyiron/pyiron_base/pull/1429:
Note:
In order to get the pip-install of the local code in the base repo working, I had to modify
cached-miniforge
like this:to
This wasn't necessary for
pyiron_ontology
(which uses pyproject.toml) nor forpyiron_workflow
(still using setup.py), and I don't know why it was needed here. Since the base PR wound up getting closed, I'm going to revert these to their simpler state. I thought maybe these hadversioneer
somewhere in their dependency tree andpyiron_base
didn't, but we're printing theconda list
now and I can see that's not the case. Without further data I'm left to conclude this is an issue withpyiron_base
being too picky and not withpyiron/actions
being too lazy. For the sake of speed, we won't pip install versioneer when we don't need to. Ahhh, no, better, let's feature-flag it.Ok, it's in
cached-miniforge
so the idea won't get lost, but I'm not going to bother exposing the input in the reusable workflows unless we need it.