search

sbdchd / django-types

:doughnut: Type stubs for Django
MIT License
202 stars 63 forks source link

Make this repo not a "fork" repo to enable github search #76

Open lpil opened 2 years ago

lpil commented 2 years ago

Hello!

This project has evolved quite a long way from the original. Would it be possible to mark it as not a fork? That way the github search feature would work.

There could be a note in the README crediting the original authors instead.

Thanks, Louis

sbdchd commented 2 years ago

Interesting, didn’t realize code search was disabled.

is there an easy way to mark it as not a fork?

maybe sourcegraph has it indexed?

lpil commented 2 years ago

I think you may have to contact support to convert it? Unsure.

bellini666 commented 2 years ago

Just to add here, wouldn't it be better to actually try to merge this back to the original lib?

There is an open discussion regarding supporting other type checks (e.g. pyright), and only using the mypy plugin for specific "django magic stuff" that is not possible to type using the existing python typing lib.

If you look at the latest 2 comments in that issue, people there seems to be open for the merge.

lpil commented 2 years ago

If merging is possible that would be grand also, though seeing as we don't know if or when that would happen it would be good to have all the GitHub features enabled here. This repo is not currently being used as a "fork" as GitHub understands it.

kylebebak commented 2 years ago

I opened https://github.com/typeddjango/django-stubs/issues/579 almost 9 months ago. I was hoping the maintainers of django-stubs could find a way to pull @sbdchd 's changes in before the two projects diverged significantly.

That didn't happen. The main branch in this repo is 85 commits ahead, and 143 commits behind, the master branch in django-stubs. The diff stats between them are 566 files changed, 11210 insertions(+), 14030 deletions(-).

Even if not all of that is real differences in code, merging these two projects now is somewhere between "huge undertaking" and "impossible". That's too bad, because the approach taken in this repo, i.e. stubs that work for any Python type checker, makes more sense.

django-stubs is built around a mypy plugin, which means the stubs only work properly when checking types with mypy. django-stubs bet big on mypy. This probably seemed like a safe bet at the time. pyright, for example, didn't exist when django-stubs was started. But things have changed a lot since then. Python has multiple type checkers. I haven't used them all, but I've used pyright and mypy a lot, and pyright is much better.

In an ideal world, django-types would be the "canonical" Django type stubs, because they're not locked in to a specific type checker. Something like the mypy plugin would be a smaller project, an optional tool built around these stubs.

intgr commented 1 year ago

django-stubs is built around a mypy plugin, which means the stubs only work properly when checking types with mypy.

I don't think this was true (I've used django-stubs without the plugin).

But regardless, django-stubs version 4.2.6 removed the dependency on mypy and we're trying to facilitate small pull requests to improve experience with other type checkers. I've opened an issue for discussion: