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

[lpil]

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]

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]

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

[bellini666]

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]

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]

I opened typeddjango#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]

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:

• Options for cooperation with django-stubs #207