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,
<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Sep 23, 2021 at 5:51 AM Stuart Prescott <<a href="mailto:
stuart@debian.org" target="_blank">
stuart@debian.org</a>> wrote:<br></div><
blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Michael<br></blockquote><div><br></div><div>Hello Stuart,</div><div> <br></div><blockquote class="gmail_quote" style="margin:0px
0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
thanks for uploading the new version of mypy :)<br></blockquote><div><br></div><div>You are welcome! <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
With the new mypy, it seems one needs a "pip install types-foo" for just about <br>
everything before it is able to usefully analyse code. I see #994830 for <br> python-types-dataclasses, and we have python3-types-toml plus python3-types-<br>
typed-ast.<br>
Are you already working towards packaging more of the split off typeshed, or <br>
do we need a bit more of a team effort on this?<br></blockquote><div><br></div><div>Good question; my answer is a question for you and the Debian Python Team:</div><div><br></div><div> 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)<br></div><div><br></div><div>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.</div><div><br></div><div><a href="
http://mypy-lang.blogspot.com/2021/06/mypy-0900-released.html" target="_blank">
http://mypy-lang.blogspot.com/2021/06/mypy-0900-released.html</a></div><div><br></div><div>If the goal is [B],
then we need to be comprehensive.</div><div><br></div><div>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). </div><div>Â <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
Does it make sense for Debian to package snapshots of all of typeshed in one <br>
binary package to save a proliferation of small python-types-foo packages? <br></blockquote><div><br></div><div>Hmm.. a joint source package makes sense (and might save the FTP team from reviewing 103 additional submissions), but as each "types-*&
quot; package in PyPI has its own public version it would be weird to not match their versions at all.</div><div><br></div><div>Though I guess the monolithic package could have a very long "Provides" line mentioning all the components and their
versions.</div><div><br></div><div> 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 :-)<br></div><
 </div><div>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.<br></div><div><br></div><div>Feedback from the wider
Debian Python community is welcome!</div><div><br></div><div>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 <a href="
https://github.
com/ltworf/typedload/pull/229">
https://github.com/ltworf/typedload/pull/229</a> to fix that need so that mypy 0.910 is unblocked from moving to Debian Testing.<br></div><div><br></div><div>Cheers,<br></div></div></div>
--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)