[
https://issues.apache.org/jira/browse/AIRFLOW-4364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jarek Potiuk reassigned AIRFLOW-4364:
-------------------------------------
Assignee: Jarek Potiuk
> Integrate Pylint
> ----------------
>
> Key: AIRFLOW-4364
> URL: https://issues.apache.org/jira/browse/AIRFLOW-4364
> Project: Apache Airflow
> Issue Type: Improvement
> Components: ci
> Affects Versions: 2.0.0
> Reporter: Bas Harenslak
> Assignee: Jarek Potiuk
> Priority: Major
>
> After a [vote on the mailing
> list|https://lists.apache.org/thread.html/f4940d36e98ded96a2473bb2ccdfa4cc648faa2c1334b2aa901c0bba@%3Cdev.airflow.apache.org%3E]
> everybody voted for pylint integration.
> Making the whole project Pylint compatible is a lot of work and big change.
> Therefore we split up all the work in subissues under this issue. The
> approach is as follows:
> All files are currently blacklisted from Pylint. The blacklist is stored in
> scripts/ci/pylint_todo.txt. Every subissue relates to one or more files on
> the blacklist. Once you start on an issue:
> # (running scripts/ci/ci_pylint.sh on master should produce no messages)
> # Remove the files mentioned in your issue from the blacklist
> # Run scripts/ci/ci_pylint.sh to see all messages on the no longer
> blacklisted files
> # Fix all messages and create PR
> *Why a separate blacklist file and not use Pylint's --ignore-pattern to
> ignore files?*
> --ignore-pattern only works on base filenames, not paths.
> *Why don't you blacklist patterns, where 1 line relates to 1 JIRA issue?*
> Creating a list of non-overlapping patterns proved difficult, this was the
> pragmatic solution.
> *Rule X is too strict. Can we disable it?*
> In the first PR ([https://github.com/apache/airflow/pull/5238]) we made a
> choice on every error found on Airflow master back then. While at occasions
> it might seem harsh to be strict on the code, Airflow is an open source
> project with many contributors from all over the world. Others read the code
> without the thought process you put into the code and it helps to have e.g.
> descriptive variable names, docstrings and sticking to Python conventions.
> This helps the collaboration between everybody and even your future self.
> Typically, this question suggests one is trying to lower the boundaries. If
> you believe there is a valid reason for doing so, please add it to the PR and
> explain the reason.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
