Make mypy a soft dependency #1628
Comments
|
+1 to this, many people (including me) primarily use the pyright implementation in Pylance, which as far as I can tell works fine with django-stubs. |
intgr
added
enhancement
|
I agree, we should change this. Other type checkers won't be able to use Personally I don't see the need to add another explicit "extra" like Any thoughts @sobolevn @adamchainz or others? |
|
I think that most people have So, I guess adding a nice error about missing |
|
@sobolevn Why do you think that most people have mypy in their requirements? And do you think that this is very much dependent on the fact that django-stubs requires mypy? Also, take into account that the most popular free python IDE, vscode, has seamless pylance (i.e. pyright) integration, whereas mypy integration is very limited and clunky in my experience (pycharm and vscode). I'm not trying to promote one type checker over another, but it's things like these that users consider when choosing/switching (static) type checkers. Given the current python-typing ecosystem, with typing definitions that are very prone to interpretation (it kinda reminds me of the first HTML5 specs), I don't think that limiting a stubs package to one single typechecker is a good idea. |
|
@jorenham this is not what I meant :) I mean: if people need mypy and django-stubs they probably have both in their requirements. That's it. If you don't need mypy, that's fine: we can make it optional. |
|
@sobolevn Ah ok, sorry for the confusion |
|
I am fine with dropping the hard dependency but I don't think we should claim any level of support, maybe even add a disclaimer. Other type checkers won't run the plugin and may interpret more complex types differently. |
|
If anyone wants to contribute better But, I don't use |
|
@sobolevn I'll give it a shot in the coming days |
|
Pyright with In |
|
Also note that we have https://github.com/sbdchd/django-types by @sbdchd, which was forked some time ago with the goal of removing mypy dependency. And maybe some of that can be merged back here to improve compatibility. |
|
Cross-posting from #1740 (comment) I want to move forward with this. Making no changes quite yet, but I propose mentioning in 4.2.5 release notes that the next next version (4.2.6) will remove hard mypy dependency. Something like:
What do you think? |
|
I would like to note that the future of "other type-checkers" right now are generally in question. I think we should really wait to see where all of this is going. I really hope that the eco-system will still be stable, but I don't want to promise things that might be affected by 3rd parties. |
My understanding from reading this thread is that we have consensus for removing the dependency on Or did you mean that I should adjust the phrasing of my proposed release notes notice to lower expectations? |
|
Yes, let's lower expectations for now :) |
|
OK, I also tried to make the message shorter. Any feedback on this one:
|
|
Maybe instead of linking to this issue, we should create a new placeholder issue, which better describes our stance on other type checkers and lists expected requirements for supporting additional type checkers? (if we can imagine what those requirements are). I'm guessing CI integration is a strict requirement, anything else? Or maybe I'm just getting ahead of myself here... |
|
Maybe "support" is too strong a word to use... -Support for other type checkers may be considered in the future, pull requests welcome.
+Improvements for other type checkers may be considered in the future, pull requests welcome.Best to start with small improvements, without committing to anything initially. |
|
Small improvements, yes, let’s just open the door a bit to see how feasible support feels before we commit to maintaining long term. |
Given that there are several popular alternatives to mypy (e.g. pyright and pytype), mypy should be an optional dependency, installable with e.g.
django-stubs[mypy].I haven't tested it myself yet, but if
django-stubsdoesn't work with these "alternative" typecheckers, then I'd suggest that it should explicitly mentioned that this is a mypy-only stubs package.The text was updated successfully, but these errors were encountered: