Release 0.3.0

[jlaehne]

Release new version 0.3.0 following releasing guide

Progress of the PR

• Prepare release,
• Changelog updated,
• changelog verified,
• test tag pushing in fork (see https://github.com/jlaehne/lumispy/actions/runs/13460214788/job/37613528129),
• Released.

[jlaehne]

DOI assignment failed in the new setup that was copied from the other extensions.
@ericpre do you have some tips what might be configered wrongly? I did the linking at zenodo only after the release, but then edited the release and managed that zenodo tried to create a doi, but failed with "errors": "401 Bad credentials".
@jordiferrero is there a kind of owner/administrator status at zenodo for the package that you could activate for me?

[jlaehne]

Something went wrong on the version setting with setuptools-scm

After updating with conda to v0.3.0, it outputs:

>>> import lumispy as lum
>>> lum.__version__                                                             
'0.0.0'

Edit:

The dev branch actually also is wrong and still states:

lumispy-0.2.3.dev

while in pyproject.toml it is correctly updated to fallback_version = "0.4.dev0"

[ericpre]

Just tried pip install lumispy in a new environment and it works fine, I get the correct version (0.3.0).
I suspect that you are importing from a local source and not the version installed in site-packages because it seems to go through the code path using setuptools_scm.

To get the correct version when running from a version controlled source, you need the latest tag, because setuptools_scm uses the tags to build the dev version.

[jlaehne]

I confirmed with a colleague having a clean conda environment and no dev versions on the PC that the conda install indeed prints 0.0.0 as version, when 0.3.0 is installed.

(the other part indeed is due to my existing local installation).

[ericpre]

In my comment above, this was with the package on pypi.org. With the conda-forge package, I can reproduce the issue and it is fixed in conda-forge/lumispy-feedstock#9.

[ericpre]

DOI assignment failed in the new setup that was copied from the other extensions. @ericpre do you have some tips what might be configered wrongly? I did the linking at zenodo only after the release, but then edited the release and managed that zenodo tried to create a doi, but failed with "errors": "401 Bad credentials".

Zenodo will create a DOI when a Github release is created (see for example: https://docs.github.com/en/repositories/archiving-a-github-repository/referencing-and-citing-content). Changing the workflow itself shouldn't affect this process.
Could it be this "bad credentials" error is related to an expired token or something similar.

@jordiferrero is there a kind of owner/administrator status at zenodo for the package that you could activate for me?

I suspect the required permission to be able to do that are on github. Could it be the "third-party application access policy" setting at the organisation level?. On my zenodo account, I can't enable/disable the lumispy one (but in comparison, I can for exspy):

[jlaehne]

I suspect the required permission to be able to do that are on github. Could it be the "third-party application access policy" setting at the organisation level?. On my zenodo account, I can't enable/disable the lumispy one (but in comparison, I can for exspy):

Thanks @ericpre for your help with both issues. I was able to enable LumiSpy on Zenodo, but I realize that @jordiferrero is the only one currently with permissions on the organization level to check the access policy.

[jlaehne]

In my comment above, this was with the package on pypi.org. With the conda-forge package, I can reproduce the issue and it is fixed in conda-forge/lumispy-feedstock#9.

Thanks, it fixed the version issue.