-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Zenodo DOI for lumispy #59
Comments
Yes, we should ... both get a Zenodo DOI and do a 0.1 release. I have no experience with either (So I do not know if one should predate the other). But am happy to contribute. |
To get a zenodo DOI, it may be need a release first. Maybe it may be worth doing two releases in a row in order to get the concept DOI in the readme and also check that the process are working fine. Relevant link to what is done for hyperspy:
Your zenodo needs to be connected to your github account and you should be able to enable automatic DOI mining on github release - which is difference from git tag. In the hyperspy release workflow, there is an action which creates the github release when a tag is pushed to the hyperspy/hyperspy repository. Note that there is a concept DOI and a per release DOI. In the readme, we include the concept DOI, because including the DOI of the each specific release is an egg and chicken issue: the DOI can't be mined before the release is done and the release can't be changed after it has been... released! There are a number of details, which are easy to miss, it is not very complicated, just tedious and not always completely documented, it not out of date, etc... Happy to help, if you need! Is it worth setting up an github action to automate the release (create sdist, wheel packages, test these packages and upload to pypi) as we do for hyperspy & co? See, for example: hyperspy/hyperspy_gui_ipywidgets#33 |
This link summarises well the process: |
Thanks for the help!
Thank you again! |
The minimum workflow is as follow:
The two last steps can be done using github actions, which I would recommend because it is not difficult to setup and avoid human mistake. conda-forge is a different story: there are a few more steps and needs to be after. Once this is done, this is all automated. |
|
I can also have a look at the actions, but never did it before either. I created a developer team for the LumiSpy organization. You probably have to give that team some rights to the repository - so far I cannot even merge PRs and the like. We would also have to include @ericpre there in order that he could help out. |
I have now hopefully given the developer team full access to everything... I have also linked Zenodo with the LumiSpy organisation. I would propose for now to target the first |
Great. As it is really just a If we use the github actions, further releases should not be so complicated and we can do another one as soon as any relevant new features are included. |
I agree. And after that first v0.1 release we can set up the actions (aka set up pip install and conda-forge install.... which may take a bit of time) |
I might at least give the actions a first try. Maybe I find some time to have a look in the next two days. |
Yes, after the first release, the installation instructions and @jlaehne, if you want to explore the github actions, you can safely play with github actions in your own repository, make/delete tags when necessary. It seems that the first upload to pypi needs to be done manually using twine: https://packaging.python.org/tutorials/packaging-projects/#next-steps, then we can create the token for the github actions. |
We have now our first release & a DOI (https://doi.org/10.5281/zenodo.4640445). I may have made some mistakes, but I wanted to get the first release out so we can correct for them. I have tried to install |
nice ;-) |
Indeed, this seems to be all good. I made a pull request to add the recipe to conda-forge, see conda-forge/staged-recipes#14406. You need to confirm that you are happy to be maintainer of the recipe and it will get reviewed and merged. Once this is done, the repository containing the feedstock will be created and you will have write access to that repository to maintain the recipe. See conda-forge doc for more details: |
Confirmed @conda. I also added a PR to add LumiSpy to the hyperspy-extensions-list: hyperspy/hyperspy-extensions-list#6 |
The conda-forge feedstock is now setup and the package works well: https://github.com/conda-forge/lumispy-feedstock. Now that there is a conda-forge package, I will add it the hyperspy bundle for the next release of the bundle - most likely just after the next hyperspy release. |
Started on the Github actions in #68 |
Thank you all for this first release! |
Hi all,
I was recently discussing on setting up a Zenodo DOI for any publication that may come from the code we are actively writing.
I have seen that both hyperspy and pyxem use such a system which keeps track of the versions for referencing.
Before I set up a Zenodo account for this repo, I wanted to discuss with you @jlaehne @ericpre if you have any objections/suggestions before going ahead.
Since we don't have any version released yet (which we should focus on soon, I think), will that be an issue with getting a DOI?
Thank you
The text was updated successfully, but these errors were encountered: