-
Notifications
You must be signed in to change notification settings - Fork 191
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
Always format modules.json after writing it #2074
Always format modules.json after writing it #2074
Conversation
It seems that some tests ( |
Yes. All the modules/subworkflows setup initialises it's test pipeline repo without git:
I guess this is the unforseen side-effect of routing everything through |
I'm actually surprised this didn't break the tests in the original PR to add this, but I am guessing none of our tests create a non-nf-core branded repo (which is also non-git), which is the only situation it was used in before. |
The tests for the function set up a git repo, create a file and run the hook on it. These tests are independent from how everything else in nf-core tools, as they should be. That was creating a capability and making sure it is working as expected. Integrating a new functionality in an often used method like dump is not unlikely to raise some flags. In the current failing test it will be mostly a question of making sure the the test actually runs in a git repo. Which is a valid expectation for any module because git is at the core of it all. |
The tests for the function are what they are and they all pass, but for whatever reason there is a provision to create nf-core repos without
We could simply revert to the old behaviour of an exception during prettier invocation not being fatal? So instead of raising a |
@awgymer Thank you for all the testing and feedback! Moving from a failure to a warning is probably reasonable and I'll update the PR accordingly. The merge of the pre-commit prettier PR came as a bit of a surprise to me as it was still labeled as WIP. But since it has been merged the next logical step is to test ride it and see how it plays with the rest of the code and how it impacts UX. Again, a WIP, because I am not sure where this PR is going ... The non-git workflow generation might be remnant of the past - introduced before git was used under the hood for a lot of the functionality. I wonder if it still has valid use cases and if it should be deprecated in the future? |
Codecov Report
@@ Coverage Diff @@
## dev #2074 +/- ##
==========================================
+ Coverage 68.00% 68.01% +0.01%
==========================================
Files 43 43
Lines 5620 5625 +5
==========================================
+ Hits 3822 3826 +4
- Misses 1798 1799 +1
Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here. |
I was not much opposed to the merge, just a bit surprised about the speed 🚀 |
Sorry @fabianegli - my fault for the fast merge 😬 I saw the Fine by me to remove the functionality to create without a git repo, I'm not sure that this is used much and a manual workaround is trivial. Agree that prettier errors should trigger a warning only and not a failure 👍🏻 |
Does that apply to syntax errors as well? They are currently raising a ValueError. And I think they should because this should never happen. |
The downside of killing execution with an error is that it often leaves things in a half-done state. For example, modules half installed or so on. In my experience it's usually easier to log an error and keep going, then let the person manually run Prettier themselves afterwards and fix whatever the problem was themselves. "It shouldn't happen" is very far from "it doesn't happen" 😅 |
It's not that I disagree with that sentiment. Half done things are bad. ... but prettier will never be able to fix syntax errors 🤷 If this happens I'd expect an issue to pop up here to make the devs figure out what's going awry and fix it. |
They are going to have to fix it manually regardless. By exiting early with an error - instead of just logging it (as critical if you want) and printing a big message to explain they need to fix it - you risk breaking a bunch of other stuff which they may have to rectify manually but won't necessarily even be reported as broken. |
Change prettier syntax errors to issue a log instead of error out Co-authored-by: Fabian Egli <fabianegli@users.noreply.github.com>
Now the tests checking for the ValueError on syntax error will fail and need fixing... |
Always format modules.json after writing it.
Closes #2047
PR checklist
CHANGELOG.md
is updateddocs
is updated