Remove inappropriate lint messages

[CasperWA]

Also, update mongo transformers, satisfying linter - no content or behaviour changes, other than introducing some raising, where appropriate.

[codecov]

Codecov Report

Merging #90 into master will decrease coverage by 0.04%.
The diff coverage is 54.54%.

@@            Coverage Diff             @@
##           master      #90      +/-   ##
==========================================
- Coverage    85.1%   85.06%   -0.05%     
==========================================
  Files          38       38              
  Lines        2216     2209       -7     
==========================================
- Hits         1886     1879       -7     
  Misses        330      330

Impacted Files	Coverage Δ
optimade/models/jsonapi.py	88.63% <ø> (ø)	⬆️
optimade/validator/__init__.py	13.04% <ø> (ø)	⬆️
optimade/models/structures.py	83.33% <0%> (ø)	⬆️
optimade/models/entries.py	100% <100%> (ø)	⬆️
optimade/filtertransformers/mongo.py	75.19% <55%> (-1.28%)	⬇️

---

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 080703c...f92d914. Read the comment docs.

[ml-evs]

Do you think we should add flake8 (or similar) to the travis? It can be very annoying to have flake8 issues reported on the same footing as test failures, so maybe we could try the new github actions?

[fekad]

Thanks, @CasperWA I think it looks nice. Please feel free to ignore my comments anytime (they are mostly about coding style more than functionality). There is one thing: I think the TransformerError never will be raised so it is misleading. The lark-parser runs in its own try block and it will raise its own error even before calling these functions. The only scenario when it could happen if you modify the grammar but in that case, you must update the Transformer as well...

[CasperWA]

Do you think we should add flake8 (or similar) to the travis? It can be very annoying to have flake8 issues reported on the same footing as test failures, so maybe we could try the new github actions?

I was indeed considering adding the pre-commit run as a test, don't know if this will be enough?

[CasperWA]

(...) There is one thing: I think the TransformerError never will be raised so it is misleading. The lark-parser runs in its own try block and it will raise its own error even before calling these functions. The only scenario when it could happen if you modify the grammar but in that case, you must update the Transformer as well...

I didn't know this, so I have removed TransformerError and adapted the class.

In order to combine both programming styles (using elif, while also sticking to the linting pointers) I have create local variables, where needed or been "clever" (see known_op_rhs). Hopefully the "cleverness" doesn't compromise the readability?

Concerning the non-existing elifs in set_op_rhs, they can be implemented alongside the actual implementation :)

[CasperWA]

Do you think we should add flake8 (or similar) to the travis? It can be very annoying to have flake8 issues reported on the same footing as test failures, so maybe we could try the new github actions?

👍 for GitHub Actions. We are currently starting to use it in our other repos at EPFL, it seems really nice. Unfortunately, I have not been part of the people setting it up. If you have experience with GitHub Actions, I would push hard for this :)

[ml-evs]

Do you think we should add flake8 (or similar) to the travis? It can be very annoying to have flake8 issues reported on the same footing as test failures, so maybe we could try the new github actions?

👍 for GitHub Actions. We are currently starting to use it in our other repos at EPFL, it seems really nice. Unfortunately, I have not been part of the people setting it up. If you have experience with GitHub Actions, I would push hard for this :)

I'll have a play around with this later today if I get time, does it make sense to add it in this PR?

[CasperWA]

I'll have a play around with this later today if I get time, does it make sense to add it in this PR?

I wouldn't say it is. But we can make it, if you want. Then the title should also be changed though.
I think the cleanest is simply to just finish this and do GitHub Actions / extra checking and testing in a separate PR?

[ml-evs]

I wouldn't say it is. But we can make it, if you want. Then the title should also be changed though.
I think the cleanest is simply to just finish this and do GitHub Actions / extra checking and testing in a separate PR?

Roger that. I have no strong feelings about the style in this PR provided it now pleases the linter, so will accept and leave it for you to decide whether to wait for @fekad!

[CasperWA]

Roger that. I have no strong feelings about the style in this PR provided it now pleases the linter, so will accept and leave it for you to decide whether to wait for @fekad!

Cheers. I will wait for @fekad, since I am touching the Mongo filtertransformer.

[fekad]

Looks perfect for me