[REF] pylint script: Migrate bash pylint script to python.

[moylop260]

No description provided.

[pedrobaeza]

All messages are errors?

[moylop260]

Yes, here return all checks activated in cfg and found.
If a check is returned then is a fail. (Currently bash script is working equal)
If you dont want a fail then you remove the check from cfg file

[pedrobaeza]

Thanks for the clarification

[pedrobaeza]

OK then

You have my 👍

[moylop260]

@pedrobaeza
Thank for your comments.

[moylop260]

FYI travis-build using this PR without pylint fails and other one travis-build-w/fails

[pedrobaeza]

@dreispt, @yvaucher, @ALL, can you review this as it's easier to review to move on with each point?

[yvaucher]

👍 just discovered the click pylib

Thanks @moylop260

[nhomar]

👍

[moylop260]

Give me a second please, before of merge.
I'm testing a case...

[moylop260]

By the good comment of @pedrobaeza
I did consider adding the test to see if he was right.
The second commit have this case considered and fixed.
My apologies for not anticipate at the time.

👍

NOTE: Can live with 2 commits (no rebase) for don't have that change the other progressive PR (just a git pull)?

[moylop260]

I merged this PR in our forked project and work fine!
What is the next step we will wait another plus one or we can merge it?

[pedrobaeza]

We have 3 approvals, so merging to continue with next steps

[lepistone]

Hi all, I have a failing build here:

https://travis-ci.org/OCA/runbot-addons/jobs/76416680#L241

Unless anyone sees the problem real quick, what do you think about reverting this one? Thanks!

[moylop260]

@lepistone
I will to run a travis2docker to detect this problem.
Can you give 25 minutes, please?

[lepistone]

thanks a lot @moylop260

[moylop260]

@lepistone
I could reproduce the error into a docker with travis2docker.
The problem is that the folder:
ls ${TRAVIS_BUILD_DIR}
is empty
We don't have to consider it this case in our script.

I will to fix it to exit(0) and print a msg when the path is empty.

Now, with or without this fix... in your builds the lint's never are checked.
Is this a expected feature?

Maybe you could add an if before to rm all modules if is a lint check here:
rm -rf $(ls | grep -v runbot$)
https://github.com/OCA/runbot-addons/blob/8.0/.travis.yml#L36

[lepistone]

Thanks for your answer @moylop260. I'm lost here: I don't see why should the rm directive be relevant: it deals with a dependency (odoo-extra) that should not be under test. We are testing runbot-addons.

Also can you explain about TRAVIS_BUILD_DIR? I don't get that neither.

[moylop260]

Ok, I got it
The command rm -rf $(ls | grep -v runbot$) is executed into default folder ${TRAVIS_BUILD_DIR}
You need to change the command with the full path:
rm -rf $(ls ~/odoo-extra | grep -v runbot$)

[moylop260]

FYI http://docs.travis-ci.com/user/environment-variables/#Default-Environment-Variables

[moylop260]

I have created a new video with your current case video

[lepistone]

Thanks @moylop260! OCA/runbot-addons#53

[moylop260]

I will to add this case in our selftest of MQT and fix it to catch this problem.

[guewen]

I disagree with the addition of the click library here.
As neat as this lib can be, I think we shouldn't use it in MQT for the following reasons:

• the code which runs the tests should be as simple as possible, adding a new dependency such as click increases the chances of bugs
• MQT must be installed on every build, so it should be as fast as possible. Adding a new dependency should be considered with care
• Click (a CLI library) is useless on Travis, there is no human on Travis to use the CLI
• Ultimately, if you really want a CLI because you clone the MQT on your project, there is nothing here that can't be done with the standard lib.

[moylop260]

I can work to remove click after of finish all my pending pylint pr without problem.
I'm agree with you.
I just used because I saw guidelines and I dont found nothing that deny it.
I appreciate if you add your cool rules in our guidelines.

[moylop260]

And Can you add in guidelines our "standard lib" list too, please?

[guewen]

Which guidelines do you talk about?

[nhomar]

2015-08-21 8:32 GMT-05:00 Guewen Baconnier notifications@github.com:

Which guidelines do you talk about?

Guidelines that explicit say "What is considered 'Use a new lib' and what
is considered 'Use a python lib'?

If the feature "USe click" is considered a feature, we should have a
guideline that explicitally mention that we should make a separate PR.

For use use click is part of "use the tools"!

---

Saludos Cordiales

CEO at Vauxoo https://www.vauxoo.com Odoo's Gold Partner.

[image: --]
Nhomar Hernandez
[image: http://]about.me/nhomar
http://about.me/nhomar?promo=email_sig

[guewen]

@nhomar We shall not have a guideline forbidding the usage of external libraries. Taking the decision to add a new library should be motivated by good reasons and it is not the matter of rules or guidelines but is exactly the matter of code reviews. Against click in the MQT, my arguments are explained here #229 (comment) and I am disposed to expand on them if required.

@moylop260 The argument parsers of the Python Standard Library are optparse and argparse.

[yvaucher]

Now, I tend to agree with @guewen MQT should be light and super fast, it is intended to be launched only by travis and several times by hours. What we could do is making other repos to be used by humans implementing a more user friendly way of launching lints and tests which could be less lightweight based on MQT files.

[pedrobaeza]

But with these changes you still have a super-fast suite, but more understandable and hackable (certain blocks of code are not executed if not activated with parameters). I don't really understand your reluctancy...

This PR is merged already 4 days ago, and you can check new Travis checks. You won't find any difference in times before and after this change.

[nhomar]

On this point about the "fast suite" everybody is agreed, no question about that, and that is a topic which is considered also here.

In futures points we can tend to discuss about "specific" topics, because if we continue talking generally speaking without specific topics then simply we are wasting lot of time.

Are you agreed to discuss this on the proper mailing list?.