Maint/modernize #76
Maint/modernize #76
Conversation
This aligns xncml enum parsing behavior with xarray's netCDF4 backend behavior.
- migrate builder from setuptools to flint - migrate doc structure - move sources to /src/xncml/ dir (was in /xncml) - migrate mardown to rst - update cookiecuttered files with relevant xncml info
|
This PR adds an AUTHORS.rst file with the information (including public github emails) from the recorded contributors: @andersy005, @huard, @Zeitsperre, @aulemahal, @fmigneault, |
CONTRIBUTING.rst
Outdated
| Before preparing an initial release on conda-forge, we *strongly* suggest consulting the following links: | ||
| * https://conda-forge.org/docs/maintainer/adding_pkgs.html | ||
| * https://github.com/conda-forge/staged-recipes | ||
|
|
||
| In order to create a new conda build recipe, to be used when proposing packages to the conda-forge repository, we strongly suggest using the ``grayskull`` tool:: | ||
|
|
||
| $ python -m pip install grayskull | ||
| $ grayskull pypi xncml | ||
|
|
||
| For more information on ``grayskull``, please see the following link: https://github.com/conda/grayskull | ||
|
|
||
| Before updating the main conda-forge recipe, we echo the conda-forge documentation and *strongly* suggest performing the following checks: | ||
| * Ensure that dependencies and dependency versions correspond with those of the tagged version, with open or pinned versions for the `host` requirements. | ||
| * If possible, configure tests within the conda-forge build CI (e.g. `imports: xncml`, `commands: pytest xncml`). |
There was a problem hiding this comment.
Consider some make release-conda or similar.
There was a problem hiding this comment.
I don't think it's necessary to create a make release-conda as the initial step for the conda-forge release requires manual step to create the conda-forge feedstock and then, when creating new releases, conda-forge should automatically get the pipy release and create a PR on the feedstock.
There was a problem hiding this comment.
In all honesty, I wrote this to provide some guidance for new maintainers. If it's irrelevant (i.e. the project was already on conda), there's no harm in removing it.
Perhaps this kind of information would be helpful in a separate documentation file specific for maintainers creating the project from the cookiecutter template that can be more easily removed?
There was a problem hiding this comment.
I'm fine either way if it feels overkill for this use case.
I personally prefer to push for the make ... approach because it allows abstraction (CI doesn't need updates if the tool changes) and to keep all the logic together in Makefile rather than spreading it around with custom tweak and combinations of various tool commands.
There was a problem hiding this comment.
@Zeitsperre I agree, I think this would fit better in a doc/development/release.rst document as it's rather the job of maintainers and not of the developers.
@fmigneault I also agree. However, one place where most tools are duplicated is the pre-commit config.
I wonder if we can tell pre-commit to run a make lint and make format instead of it fetching these steps from other git repositories.
BTW, that's pretty much the approach of javascripts projects using husky, they define the lint, format, etc, commands once in a versioned package.json and in the pre-commit config of husky, they just call these commands.
|
Many thanks for your review @fmigneault, there are some xncml specific issues indeed, but I think most of your comments should first be applied to the cookiecutter template. |
Co-authored-by: Francis Charette-Migneault <[email protected]>
Co-authored-by: Francis Charette-Migneault <[email protected]>
|
@bzah Thanks for the heads-up! I'm still coming back from my vacation, so I'll give this a look as soon as I can. @fmigneault If you'd like to upstream a few of your changes so that the nearly 10+ projects using it can also benefit from your work, you are more than welcome to open a PR! |
|
I'll let @bzah do it. I only did the proposals, but he did all the good work behind these commits 😉 |
|
@Zeitsperre no worries, I will be working on this PR and upstream what's relevant in the coming weeks. |
xncml no longer support python 3.8
|
It looks like numpy 2.0.0rc1 on python 3.12 breaks some automated tests. I will have a look and try to fix this in another PR. |
Moved the 'how to release' from the contributing guide to a dedicated releasing.rst guide.
|
Once the changes have been merged to the main branch of the template, I think we can fast-forward those changes here and safely merge! |
|
@Zeitsperre I will try to update this branch via cruft tomorrow. I'm away for a month on Wednesday, so I hope I can get something clean and we can merge this one before I leave. |
|
@fmigneault The changes coming from the cookiecutter template are done, IMO. The last tasks needed now require Admin access (setting tokens for the repo and registering the project on outside platforms). |
|
I'm not sure who has the admin rights to setup the tokens. Perhaps, we could disable the use of bumpmyversionm, scoreyard and Coveralls so that this PR can move forward. |
|
@bzah I'm going to fast-forward the cookiecutter to the latest commits to see if we can finalize this. For the token-related issues, we need someone with admin privileges to get that up and running (or to share those privileges so that I can put them in place). @huard Are you able to set these things up? Edit: Thanks David! |
Zeitsperre
force-pushed
the
maint/modernize
branch
from
f088e62
to
ded5681
Compare
Zeitsperre
force-pushed
the
maint/modernize
branch
from
51b069c
to
585e6e1
Compare
Pull Request Test Coverage Report for Build 9811258437Details
💛 - Coveralls |
|
@bzah and @andersy005 (also @huard) The last things missing are the personal access tokens. Relevant StackOverflow: https://stackoverflow.com/questions/75044318/create-personal-access-token-request-for-organization Additionally, since I'm not a member of An alternative approach to making a personal access token tied to an individual user is to create a GitHub App to manage this (I've performed this recently for @Ouranosinc: https://github.com/apps/ouranos-helper-bot; It's relatively simple, but the maintainer again would need to be a member of the organization). This is the last thing blocking this PR. Let me know if you have any questions. Best, |
Thanks for submitting a PR, your contribution is really appreciated!
Here's a quick checklist that should be present in PRs (you can delete this text from the final description, this is just a guideline):
[summarize your pull request here]
This PR fixes #69.
The aim is to modernize the tooling surrounding
xncml, including but not limited to:pyproject.tomlruffinstead offlake8,isort,black, etc.This also adds a
.cruft.sjonfile coming from the use of cruft with the ouranosinc template.Cruft can then be used to update the project structure whenever the template is updated.
However, xncml porject already diverged a little from the original template:
Breaking changes
flitinstead of setuptoolstoxand reports directly to coveralls.ioTODO