Something weird with versioning?

[liamhuber]

I have pyiron_gui as a dependency over in ironflow, but I ran into two weird issues:

First, it tried to install 0.0.7 (which was incompatible with the latest version of pyiron_base). I still don't understand why it tried this, since 0.0.8 is available. Pinning the dependency to 0.0.8 worked fine, which is nice but really surprised me -- if 0.0.8 wasn't generating a environment solution issue, why was mamba pulling out 0.0.7?

Second, when I run the standard pip-check CI it borks on pyiron_gui and claims I'm running a dev version (ironflow 0.post0.dev1 has requirement pyiron-gui==0.0.8, but you have pyiron-gui 0.post0.dev30.). You can see the full CI stack trace here, and mamba is clearly pulling 0.0.8, so I wonder if the pip wheel is building with the wrong version built in or something? I went one step further and launched binder for that pr of ironflow, and inside binder I can indeed import pyiron_base; pyiron_base.__version__ and see 0.5.28 as expected and desired, but import pyiron_gui; pyiron_gui.__version__ gives '0+unknown', which is consistent with pip borking but obviously not the version I expected to have.

I'll look more into it myself, but I'm still learning the ropes with releasing and packaging stuff, so if anyone else has insight into what pip/versioneer might be doing here it would be appreciated. @pmrv and @srmnitc, you're maintainers on the gui feedstock so I'm going to explicitly pick on you with "@"s.

[jan-janssen]

When I download the package from pip and call pyiron_gui.__version__ I get -0.0.8, so I can see that a negative version is difficult to parse.

[jan-janssen]

I created a patch for the conda package conda-forge/pyiron_gui-feedstock#12

[liamhuber]

Perfect, thanks! The only meaningful difference I see is the yaml -> jinja-yaml and "py-lief<0.12" passed to the conda build -- the rest look like changes for removing Muhammad from the maintainers list. These are not present in pyiron_base though, and things still work fine there.

Aha, the setup.py has an actual diff: the kwarg cmdclass=versioneer.get_cmdclass(),. Ok, and I can also see that this line is present in our other repos. Thanks! I don't know what the setup kwargs all do and it would not have occurred to me to check for that.

I see that you closed #190 -- don't we still need to merge this so that future releases will also work?

[liamhuber]

Nevermind, just saw #192

[liamhuber]

I'm still getting trouble. The version is updated now, but pip is still sad -- used to be 0.post0.dev30, now 0.post0.dev38. Dealing with something else then I'll take another look at this.

Run pip check
  pip check
  shell: /usr/bin/bash -l {0}
  env:
    INPUT_RUN_POST: true
    CONDA: /usr/share/miniconda3
    CONDA_PKGS_DIR: /home/runner/conda_pkgs_dir
    DATE: 20221121
ironflow 0.post0.dev1 has requirement pyiron-gui>=0.0.8, but you have pyiron-gui 0.post0.dev38.

[jan-janssen]

Yes, I needed to release a new version conda-forge/pyiron_gui-feedstock#13

[jan-janssen]

So the background is that with the new line, the _version.py file inside the pypi package already contains the version information as JSON. As a consequence rebuilding the conda package was not sufficient, but the new release 0.0.9 works.

[liamhuber]

Yes, I needed to release a new version conda-forge/pyiron_gui-feedstock#13

Beautiful, worked perfectly.

So the background is that with the new line, the _version.py file inside the pypi package already contains the version information as JSON. As a consequence rebuilding the conda package was not sufficient, but the new release 0.0.9 works.

Thanks for the explanation! That makes sense, but is another thing I would not have anticipated.

If we now set the 0.0.9 tag as a "release", will we run into trouble with the deploy CI re-running?
Edit: that is to say, I believe it will re-run, I just don't know if invoking the pypi deployment twice causes any hiccups.

[jan-janssen]

If we now set the 0.0.9 tag as a "release", will we run into trouble with the deploy CI re-running?

I created the 0.0.9 tag, so the next tag would be 0.0.10 - everything is fine with the CI.

[liamhuber]

I created the 0.0.9 tag, so the next tag would be 0.0.10 - everything is fine with the CI.

Yeah, I found the tag without trouble, but it's not labeled as a "release" (with changelog etc). Making a release from the tag is really easy, I just don't want to bork the pypi by doing so. If you haven't done it before or don't know how pypi will respond I think I'll just go for it and see what what happens -- I have 0.0.10 waiting in the wings anyhow (#188)

[jan-janssen]

Oh I see, I guess it should be fine, as the trigger for the CI is the tag and the release is just some additional information for the tag.