Skip to content
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

automatted reformatting / improve linting #265

Open
HerrMuellerluedenscheid opened this issue Nov 3, 2021 · 2 comments
Open

automatted reformatting / improve linting #265

HerrMuellerluedenscheid opened this issue Nov 3, 2021 · 2 comments

Comments

@HerrMuellerluedenscheid
Copy link
Contributor

The linter is run as part of each module tested in the same stage. I think there are more projects that run the linter as a stage before the actual test stage to scope the problems a little better, which makes sense to me. @priv-kweihmann What do you think about running the style checks first before executing tests? Also, the tests take quite a long time to finish. It's a little annoying when those 20 minute test sessions fail because of a style issue which could have been caught at an earlier stage.

Many linters (such as black) allow automatted reformatting so that I as the contributor don't have to think about style at all. Is there a way to fix the contributed code automatically given the linters used in oelint or is there no way to get around manual labor?

@priv-kweihmann
Copy link
Owner

Well yes we could do that. I set it up like this out of the following reasons

  • one common interface (pytest)
  • one common configuration file (setup.cfg)
  • same behavior locally and in CI

I'm definitely not the pytest expert in here, so I might need a little help to untangle this into two separate stages, while keeping the above mentioned points.

Still I'm open to your idea - expect one point (:smile: )... I don't want any auto-formatting done as part of the CI.
Every change done to this repo has to be in the same state as the author committed it to.
Otherwise we need to have

  • a bot with write access to this repository
  • a set styleguide ( 😉 )
  • a defined way how to deal with unwanted modifications by the bot (and yeah I've been there unfortunately)

A possible way out is to promote the usage of pre-commit hooks or similar, so the modification still happens before the actual commit (that would be okay for me).

@HerrMuellerluedenscheid
Copy link
Contributor Author

HerrMuellerluedenscheid commented Nov 3, 2021

Love your suggestion using pre-commit ! Let's do that

Just to avoid confusion: I'm not advocating to do the fixing automagically in the CI, but the verification that a user has done the linting (a la black --check). With black we don't need have a styleguide in place. That's the most charming aspect about black - It gets rid of discussion (:

To clarify: I (and probably other future contributors) would love to have something like black, make format, pre-commit, prepare-commit-without-using-my-brain.sh or alike that I can run that takes care of the style, so I don't have to manually replace double quotes with single quotes, add commas at end of lines, etc.. waste of time.

I'll give a shot overhauling the tests maybe this weekend if I find the time to rule out some pitfals.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants