Pylint crashes if Django is not configured #277
Comments
That's because Django needs its settings, see the docs:
Your FK reference is specified as a string so pylint-django tries to resolve it using the Django utilities and fails with missing settings. This happens here: https://github.com/PyCQA/pylint-django/blob/master/pylint_django/transforms/foreignkey.py#L102 In case we get an error we'll try to fallback and append This whole thing exists because Django doesn't follow its own practices to have
If your editor doesn't allow you to configure the pylint command then how does it know to run pylint-django as a plugin ? If this is an actual fact then I'm curious to know what exactly do you use for development. OTOH IDEs (not plain editors) always allow you to configure the command which gets executed, although this might be cumbersome sometimes. Disclaimer: I'm not a fan of IDEs and use Makefile to configure how I run things. @carlio, @alejandro-angulo - while the above LookupError exception can be extended to also include ImproperlyConfigured I'm not confident we should go this way. If we start ignoring the missing configuration then I suspect there will be a bunch of false results for the unresolved FK references and a lot more bugs reported by people who haven't configured their environment. What's your opinion ? And FTR we've spent too much time dealing with this issue of FK references as strings that I'm starting to regret we even worked on it in the first place. It is usually a code smell like previously discussed in #243 (comment). |
|
I agree that ignoring |
|
Hi again, and thanks for the replies! While I understand that using string-references is not ideal, we are in a situation where we have a Django project with hundreds of models that have circular references to each other. The easiest way to deal with this is to use string-references, as python doesn't like circular imports. I understand that handling this in a pylint plugin is be hard (we've had issues with this for a long time and I've already tried to fork pylint-django to find a solution), but just plain crashing seems like a really bad developer experience. Wouldn't it be better to catch the error and emit a warning or something like that? We've had pylint running with pylint-django for a long time with the exact same configuration and it just started crashing on 2.2.0. It seems to me like with these changes |
What's the difference of a flag vs ENV variable ? Could be an if condition to check whether or not ENV is available though. Edit: this will lead to the situation where people skip over the details in the documentation and string resolution stops working for them in some cases, so not very different from what I've described earlier. |
I'm not a fan of this, check-out this talk for more context https://www.youtube.com/watch?v=nCGBgI1MNwE. You get a warning which people will ignore then start asking question why this and why that and etc. Not ideal either so why bother ? If it crashes at least you know something's up.
Yes, it is a required. That's why the documentation has been updated although it doesn't say explicitly that it is required. But it is there on the command line. But nothing is stopping you to pass
Correct, the defaults in manage.py is just a glue layer for Django. |
|
@atodorov I agree, having just a warning means that some people just ignore it then act confused when behaviour isn't as documented then come to the comments. My main learning (and regret!) from prospector is that if you try to make it so anyone can configure it to their environment, you end up needing to support many many different environment types which requires a lot of overhead in terms of issues. I'd recommend a much more simple "because you require feature X, you must do Y" error (or fatal) and leave it at that. As long as the error has a clear message with instructions (or a link to the relavent piece of the docs) I think that's the best solution. |
I was thinking that a flag would require an explicit action from the user to enable (similar to the additional migrations checker plugin). But then, like you said, there will inevitably be some people that don't read the documentation. Checking if the environment variable is set sounds like a good solution to me. It should work as expected for existing users (no change in behavior if the variable is not set) and I think it would require minimal changes to the documentation (just an update to indicate that Django's resolution will be used if the variable is set).
Good counterpoint to checking for an environment variable. My only concern then is that maybe 2.2.0 should have been 3.0.0, since it introduced a backwards incompatible change. |
@carlio this is simple enough and sounds good to me. And I can bump the version to 3.0, even remove 2.2.0 from PyPI to make it more obvious something big has changed. |
if Django isn't configured, that is DJANGO_SETTINGS_MODULE isn't available in the environment, then raise a RuntimeError with message DJANGO_SETTINGS_MODULE required for resolving ForeignKey string references, see Usage section in README!
if Django isn't configured, that is DJANGO_SETTINGS_MODULE isn't available in the environment, then raise a RuntimeError with message DJANGO_SETTINGS_MODULE required for resolving ForeignKey string references, see Usage section in README!
if Django isn't configured, that is DJANGO_SETTINGS_MODULE isn't available in the environment, then raise a RuntimeError with message DJANGO_SETTINGS_MODULE required for resolving ForeignKey string references, see Usage section in README!
…he `open()` pre-configuration. This allows the django settings module to be set from a command-line option or .pylintrc option as well as an environment variable (refs #286). This commit also uses default Django settings if none are specified, raising an error to the user to inform them that it is better to set it explicitly, but avoiding the need to raise a Fatal or RuntimeError if Django is not configured (refs #277 and #243)
Hi there, starting with version 2.2.0 I'm seeing a crash if django is not properly configured. I'm assuming this is originating from #243. This happens even if the string foreign key is resolvable without using the Django runtime.
While I kinda understand that you'd expect to have a Django configured while running pylint, it's not always the case and in some cases it might be hard (like in an editor).
pip freeze:The text was updated successfully, but these errors were encountered: