[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: mypy and typeshed





On Thu, Sep 23, 2021 at 5:51 AM Stuart Prescott <stuart@debian.org> wrote:
Hi Michael

Hello Stuart,


thanks for uploading the new version of mypy :)

You are welcome!

With the new mypy, it seems one needs a "pip install types-foo" for just about
everything before it is able to usefully analyse code. I see #994830 for
python-types-dataclasses, and we have python3-types-toml plus python3-types-
typed-ast.

Are you already working towards packaging more of the split off typeshed, or
do we need a bit more of a team effort on this?

Good question; my answer is a question for you and the Debian Python Team:

Do we package mypy to [A] support other packages, or are we trying to [B] deliver a "complete" offline developer experience? (even if that means shipping type hints for python packages not in Debian)

If the goal is [A], then we should stick to the add-hoc approach: "python-types-*" packages will only be made as needed for building other Debian source packages in our archives. In this instance, developers using the packaged version of mypy can use `mypy --install-types' to pull down the packages they need from PyPI to their local system/virtualenv.

http://mypy-lang.blogspot.com/2021/06/mypy-0900-released.html

If the goal is [B], then we need to be comprehensive.

Either way we choose, updates to these type hints may need to be made (and patches applied) to match the versions of the Python packages in the archive (if they have fallen behind or ahead of what is in the typeshed repository).
 
Does it make sense for Debian to package snapshots of all of typeshed in one
binary package to save a proliferation of small python-types-foo packages?

Hmm..  a joint source package makes sense (and might save the FTP team from reviewing 103 additional submissions), but as each "types-*" package in PyPI has its own public version it would be weird to not match their versions at all.

Though I guess the monolithic package could have a very long "Provides" line mentioning all the components and their versions.

The Copyright file will be interesting! For the two "python-types-*" packages I created by hand, I had to dig up the author information from the git history at the urging of the FTP gatekeepers :-)
 
Personally I'm more of an [A] person (out of laziness), but I won't block the [B] approach if there is sufficient interest that it doesn't primarily fall on my shoulders.

Feedback from the wider Debian Python community is welcome!

P.S. From the [A] perspective python-types-dataclasses is not needed as that is a backport for Python <= 3.5 so I'm working with the maintainer of typedload at https://github.com/ltworf/typedload/pull/229 to fix that need so that mypy 0.910 is unblocked from moving to Debian Testing.

Cheers,

Reply to: