Closed timmens closed 4 months ago
Check out this pull request on
See visual diffs & provide feedback on Jupyter Notebooks.
Powered by ReviewNB
I sometimes get this warning when running pre-commits. Maybe you can fix it with your PR
warning: The top-level linter settings are deprecated in favour of their counterparts in the `lint` section. Please update the following options in `pyproject.toml`:
- 'extend-ignore' -> 'lint.extend-ignore'
- 'select' -> 'lint.select'
- 'pydocstyle' -> 'lint.pydocstyle'
- 'per-file-ignores' -> 'lint.per-file-ignores'
- Should we rename the old token secret from
PYPI_API_TOKEN
toPYPI_API_TOKEN_ESTIMAGIC
. In this case we would need to create a new one.
No, having PYPI_API_TOKEN
and PYPI_API_TOKEN_OPTIMAGIC
is clear enough and we don't need to spend time on the renaming.
Find a better place than the new folder .scripts to store the python file update-name-in-pyproject.py. Proposal: Combine contents of .scripts folder with .envs folder in new folder called .ci.
Yes, we should combine all pre-commit hooks in one folder but the resulting environment files should still stay in .envs
. .ci
is not a good name because we will soon have a lot more pre-commit hooks that are actually code generation tools and not related to quality assurance (see here for details). We might also have related pytest hooks. I am almost indifferent between the names .scripts
and .tools
but would not get more specific.
Warning looks like this:
PYPI_API_TOKEN_OPTIMAGIC
as secret to repoOpen Questions:
PYPI_API_TOKEN
toPYPI_API_TOKEN_ESTIMAGIC
. In this case we would need to create a new one. -> No.scripts
to store the python fileupdate-name-in-pyproject.py
. Proposal: Combine contents of.scripts
folder with.envs
folder in new folder called.ci
. -> We will use .tools for everything nowmypy discussion
For now, I have opted to keep both the mypy pre-commit and the mypy GitHub Action task. Given tools like
pre-commit CI
, I see an advantage in not using the development environment for the hooks. However, since we are not entirely sure that this mypy call is doing the same thing that the mypy call from our dev environment is doing, I believe the GitHub Action task is necessary. Combined, we should (1) be able to gain some experience with pre-commit mypy, (2) ideally get quick errors before committing, and (3) be confident that all errors should be caught, at least after pushing.