# Pylint and ease of development **URL:** \ **Category:** Architecture\ **Created:** [February 24, 2025, 9:13pm UTC](https://discuss.openedx.org/t/pylint-and-ease-of-development/15085 "2025-02-24T21:13:06Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![jesperhodge](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/jesperhodge/32/4647_2.png) [@jesperhodge](https://discuss.openedx.org/u/jesperhodge)\ **Post date:** [February 24, 2025, 9:13pm UTC](https://discuss.openedx.org/t/pylint-and-ease-of-development/15085/1 "2025-02-24T21:13:06Z")
I propose we re-evaluate and streamline the linter rules across Django repositories—especially edx-platform—to enhance code quality while significantly reducing developer frustration and time loss. **Key Issues:** - **Overwhelming and Unclear Rules:** - The current linter setup includes too many rules with unclear guidelines, leading to confusing error messages. - Developers often spend excessive time trying to decipher and fix these issues, sometimes triggering additional errors in the process. - **Integration Challenges:** - The complexity of our development environments (e.g., docker setups, devstack, tutor) makes it difficult to integrate linter feedback directly into code editors, exacerbating the problem. **Recommendations:** 1. **Simplify and Consolidate:** - Reduce the number of linter rules to focus on high-impact areas like maintainability, readability, and bug reduction. - Adopt a single, consistent linter to avoid conflicting or redundant rules. - Evaluate actual maintainability problems in the codebase - e.g. functions with high cyclomatic complexity - and make that the guideline for choosing linter rules 1. **Enhance Integration and Automation:** - Improve integration with code editors to display linter feedback immediately and understandably. - Automate routine tasks (such as import reordering via isort in CI) to reduce manual effort. This approach aims to uphold high coding standards while streamlining the development process and reducing unnecessary time spent on resolving linter errors. ---
**Author:** ![braden](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/braden/32/46_2.png) [@braden](https://discuss.openedx.org/u/braden)\ **Post date:** [February 24, 2025, 10:23pm UTC](https://discuss.openedx.org/t/pylint-and-ease-of-development/15085/2 "2025-02-24T22:23:27Z")
> [@jesperhodge](#): > > - The current linter setup includes too many rules with unclear guidelines, leading to confusing error messages. > - Developers often spend excessive time trying to decipher and fix these issues, sometimes triggering additional errors in the process. Do you (or others) have any specific examples to share? > [@jesperhodge](#): > > difficult to integrate linter feedback directly into code editors Agreed that this is a big annoyance compared to other codebases I work on where the linters run as you type. Another big problem with pylint is that it’s incredibly slow, whether integrated into your editor or not. What do you think about making a big push to replace pylint entirely with [ruff](https://github.com/astral-sh/ruff)? I think doing so could address your other concerns at the same time, as it has fewer rules than pylint anyways. ---
**Author:** ![jesperhodge](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/jesperhodge/32/4647_2.png) [@jesperhodge](https://discuss.openedx.org/u/jesperhodge)\ **Post date:** [February 26, 2025, 6:37pm UTC](https://discuss.openedx.org/t/pylint-and-ease-of-development/15085/3 "2025-02-26T18:37:52Z")
I think migrating to ruff would be a big improvement. Aside from the points you mention, it will be a huge relief that it has better formatting capabilities. Where in JavaScript we tend to use prettier, with ruff we can have it sort out most of the stylistic problems automatically. I know that migration is not super easy and may take a while, but I’m sure we can take our time with this. ---
**Author:** ![jesperhodge](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/jesperhodge/32/4647_2.png) [@jesperhodge](https://discuss.openedx.org/u/jesperhodge)\ **Post date:** [March 3, 2025, 3:26pm UTC](https://discuss.openedx.org/t/pylint-and-ease-of-development/15085/4 "2025-03-03T15:26:08Z")
I don’t have a good example for the linter problems where you fix one thing and your fix just breaks something different. However [this PR](https://github.com/openedx/edx-platform/pull/32282/commits) is a good indication of how much time linter fixes can take, looking at the number of commits that just fix lint issues. ---
**Author:** ![jesperhodge](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/jesperhodge/32/4647_2.png) [@jesperhodge](https://discuss.openedx.org/u/jesperhodge)\ **Post date:** [March 5, 2025, 8:44pm UTC](https://discuss.openedx.org/t/pylint-and-ease-of-development/15085/5 "2025-03-05T20:44:21Z")
Hi @braden , I’m just wondering what the next step here is. What needs to happen to put this in the OpenEdx backlog? ---
**Author:** ![braden](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/braden/32/46_2.png) [@braden](https://discuss.openedx.org/u/braden)\ **Post date:** [March 5, 2025, 9:54pm UTC](https://discuss.openedx.org/t/pylint-and-ease-of-development/15085/6 "2025-03-05T21:54:20Z")
@jesperhodge I’d say you should start with a proof of concept. Pick a repo, and simplify its lint rules or (ideally) replace pylint with ruff, then open that as a PR and get buy-in from people. If there’s enough buy-in, you can make an update to [the relevant OEP](https://docs.openedx.org/projects/openedx-proposals/en/latest/best-practices/oep-0067-bp-tools-and-technology.html#backend-technology-selection) then once approved, put out a call for people to help with the transition. ---
**Author:** ![jmbowman](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/jmbowman/32/123_2.png) [@jmbowman](https://discuss.openedx.org/u/jmbowman)\ **Post date:** [March 18, 2025, 11:44pm UTC](https://discuss.openedx.org/t/pylint-and-ease-of-development/15085/7 "2025-03-18T23:44:01Z")
There was an early experiment in switching edx-platform from pylint to ruff in [Try ruff linter by irtazaakram · Pull Request #33559 · openedx/edx-platform · GitHub](https://github.com/openedx/edx-platform/pull/33559) . The verdict at the time was that it wasn’t comprehensive enough to completely replace the pylint checks, but it would be great for fast local feedback loops covering a large percentage of them. Unfortunately, some chaos at 2U at the time meant that the work never got finished and merged. It looks like there was also a later attempt in [Ruff linter by awais786 · Pull Request #34820 · openedx/edx-platform · GitHub](https://github.com/openedx/edx-platform/pull/34820) . ---
**Author:** ![bryantt-v](https://sea2.discourse-cdn.com/flex020/user_avatar/discuss.openedx.org/bryantt-v/32/5283_2.png) [@bryantt-v](https://discuss.openedx.org/u/bryantt-v)\ **Post date:** [March 26, 2025, 5:25pm UTC](https://discuss.openedx.org/t/pylint-and-ease-of-development/15085/8 "2025-03-26T17:25:27Z")
Hi everyone. I’d been working in a POC to replace some libraries with Ruff in the Hooks repos. Initially, `pydocstyle` _(deprecated)_ was replaced in [this PR](https://github.com/openedx/openedx-filters/pull/270), and now, here is a [PR](https://github.com/openedx/openedx-filters/pull/275) to replaces `pycodestyle`, `isort` and `pylint` _(partially)_. All information about Pylint can be found in the PR. Any comments or suggestions are welcome! cc @jesperhodge