-
Notifications
You must be signed in to change notification settings - Fork 30
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
Format yaml files #427
Format yaml files #427
Conversation
Codecov Report
@@ Coverage Diff @@
## main #427 +/- ##
==========================================
- Coverage 92.88% 92.76% -0.12%
==========================================
Files 225 224 -1
Lines 17673 17134 -539
==========================================
- Hits 16416 15895 -521
+ Misses 1257 1239 -18
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
In order for hyphens: enable to hypens:
max-spaces-after: 3 which allows yaml files with nested lists like: history_x:
- - 0.15
- 0.008
- 0.01
- - 0.25
- 0.008
- 0.01 where the potential problem is the spacing between the two hyphens. In principle, it might be possible to align the settings of yamlfix and yamllint here, but I could not find the yamlfix option which governs this behaviour. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great to me, thanks a lot!!!
I would love to see common settings for the hooks across projects so one can easily spot differences. In particular, what would be good IMHO:
- Same order of hooks (if possible)
- Same settings for (basic) py / yaml / md linting and formatting
- Same sorting of environment files (alphabetically?)
Please append to the list if I am missing anything. I think estimagic is a good place to settle that because it's environment is close to being a superset of the others' environments.
@janosg @tobiasraabe I explicitly tagged you re the order, but it would be great if you could have a look at the other settings, too.
Partly related: yamlfix is based on ruyaml -- loading/dumping based on that would add another dependency but probably prevent some pre-commit surprises (and all of them if it could be configured according to the section in pyproject.toml). No strong opinion here, just wanted to toss it into the round.
Co-authored-by: Hans-Martin von Gaudecker <[email protected]>
In principle I like the standardization across projects, but we have tried that multiple times in the past and it always failed. Back then the idea was that there is one tiny project (I think it was called the OSE packaging guide) that always uses the latest version of pre-commits, CI and other infrastructure and each project copies from there. Typically nobody copied and thus at some point we stopped updating. I think the only way we can implement something like that would be to automate it. I think Tobi does that to some extent for the many pytask repos. But probably after automatic updates we would still have to fix problems manually and I am not sure if people are willing to do that. There are also some things we probably cannot standardize. For example I would love to enable some more ruff rules in estimagic but fixing all issues in such a large codebase takes time. In small projects we can be stricter. RE sorting: I think I prefer it if environment files are sorted by category (e.g. runtime dependencies, test dependencies, ...) but I don't have a strong opinion. I do like estimagic's new way of auto-generating variations of the development environment for testing, but probably most other packages don't need that. If we start another real effort to standardize the whole infrastructure across OSE packages, we should probably discuss that in a larger group. Definitely out of scope for this PR. |
BTW: The failing link will be fixed when you merge the main in this branch. |
My only addition to Janos' comment is that we already sort alphabetically in each category, except for the first and last line of the dependencies. |
Yeah, fair enough, I remember that and I don't think we will be able to go fully automatic.
Exactly. Different projects just have different needs. What I like to do to compare is to diff files from different projects. Three things were annoying in the past on that one:
Because of the last point, I think this is the right place to start. |
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me!
Disclaimer: Did not check all 281 files.
Closes #426.