pylint_django error – NoSuchChecker

I just spent an inordinate amount of time tracking down an issue with pylint-django that I had a hard time finding any clues on the internet about, so I’m documenting it here.

I use pylint and pylint-django to perform automated checks on my Django projects and ensure a certain code quality is maintained. This combination has proven very useful. Recently, though, I ran into an issue where one project would fail to validate with a strange error:

$ pylint --rcfile pylintrc myproject
Using config file /app/pylintrc
Traceback (most recent call last):
  File "/usr/bin/pylint", line 11, in <module>
  File "/usr/lib/python3.6/site-packages/pylint/", line 16, in run_pylint
  File "/usr/lib/python3.6/site-packages/pylint/", line 1312, in __init__
  File "/usr/lib/python3.6/site-packages/pylint/", line 495, in load_plugin_modules
  File "/usr/lib/python3.6/site-packages/pylint_django/", line 18, in register
    name_checker = get_checker(linter, NameChecker)
  File "/usr/lib/python3.6/site-packages/pylint_plugin_utils/", line 30, in get_checker
    raise NoSuchChecker(checker_class)
pylint_plugin_utils.NoSuchChecker: <class 'pylint.checkers.base.NameChecker'>


I thought maybe this had to do with some incompatibilities between pylint, pylint-django, and possibly astroid, but strangely, the versions in this project were exactly the same as the other project. So I dug into the code where the exception was being reported.

get_checker is a part of pylint_plugin_utils, and it is used by pylint-django to augment the base PyLint checkers. It was trying to find pylint.checkers.base.NameChecker in the list of registered “checkers” for pylint. The file pylint/checkers/" did exist in thesite-packagesfolder, but strangely, it was being registered assite_packages.pylint.checkers.base.NameChecker`.

Pylint has a register_plugins function that it uses to register all the default plugins. It does this by calling modutils.load_module_from_file on each of the files it finds starting from the checkers directory included with the library.

load_module_from_file figures out the proper import path using a function modpath_from_file, which in turn uses modpath_from_file_with_callback to check that each path it traverses has a file. It looks at each path in sys.path in order to determine if the file attempting to be loaded has a valid import path.

What was throwing things off was the presence of in the site-packages directory. /usr/lib/python3.6 was in sys.path before /usr/lib/python3.6/site-packages, and because there was a file in site-packages, the import mechanism thought that site-packages was itself a module in the /usr/lib/python3.6 directory. It was therefore assigning this as the module name. Now where was that coming from?


It turns out it was a rogue package that stuck that empty file there (singletons). I removed that file (and thankfully had control over the project where that file originated and removed it from the source), and that fixed the issue.

Cloud9 as a Development Environment

I first encountered Cloud9 (the IDE, not the professional gamers) a couple years ago, when I was looking for a nice HTML/CSS editor for the students in my Exploring Computer Science course to use on their own laptops. I settled on it because it had good highlighting, didn’t require them to understand anything on the command line, but still focused on raw code as opposed to WYSIWYG stuff.

Since I stopped teaching high school, I hadn’t thought much about it. As a boot camp instructor, it was important to me that I teach my students how to use “real” tools, and so we focused on local tools.

At the moment though, I find myself temporarily without a dev machine, and my mind turned back to Cloud9. I’m mainly working in libraries (hurrah for free access to computers!), and while I can thankfully count on them to have Google Chrome, I can’t count on much else.

So, how can I do some real development without a real dev machine? I started up a new (free) account to find out.

Continue reading →

Markdown in WordPress

Markdown-mark.svgI’ve been writing a lot of prose over the past year – lesson plans, online content, blog posts, etc. As more of my prose has also involved code samples, I’ve gravitated toward Markdown for writing my text for a few reasons:

  • It’s dead simple to incorporate code blocks
  • It’s cleaner to look at than raw HTML
  • There are plenty of great tools that support it (for me those include Jupyter Notebook and The Iron Yard’s online learning platform)

(Yes, there are also reasons not to use Markdown)

But I never made the jump to using it on my blog. Until today!

Continue reading →

C# on a Mac

I recently was asked to teach a guest lecture for a class in C#. Only one catch: my laptop was a Mac.

Of course, this day and age, there are plenty of options for running Windows on a Mac. Some magazines have gone so far as to declare that Macs are the best Windows laptops. However, I wasn’t interested in using virtualization or dual-booting to achieve my end goal – not least of which because I’d be required to buy a Windows license (and possibly a Visual Studio license). Rather than focusing on running Windows on my machine, I decided to see if it was possible to do some stuff Mac-native.

Continue reading →

First Impressions of Swift

Ohio was hammered with snow last night, leaving me with a snow day today. After spending an hour shoveling myself out of the driveway (which I expect I’ll have to do again to get back in), I headed to Starbucks, grabbed a coffee, and decided to look into the current state of iOS app development.

I’ve dabbled in Mac/iOS development in the past, but I’ve never made the time to build anything significant/useful. This might relate to my opinion that writing code in Objective C wasn’t really fun. I get a thrill out of writing clean Python code that works well, whereas Objective C just kind of felt a little too raw and nit-picky. I frankly don’t want to have to worry about memory management, and “NS” everywhere just seemed like unnecessary typing and clutter.

I had heard of Swift, but didn’t really know what it involved or how it was different from Objective C development. All I knew was that it was an iOS 8/Yosemite-focused language, and that it was Apple’s new thing.

Continue reading →