Re: mypy and typeshed
On Fri, Oct 01, 2021 at 08:14:20AM -0300, Antonio Terceiro wrote: > On Thu, Sep 30, 2021 at 04:29:20PM -0300, Antonio Terceiro wrote: > > Maybe I didn't dedicate enough time for this, but I couldn't figure out > > how the pypi packages are produced from the git repository. Knowing this > > would help creating such typeshed package by means of some scripting > > (not necessarily volunteering, will be happy if someone beats me to it). > > It turns out that this is done by this repository: > > https://github.com/typeshed-internal/stub_uploader I gave this a try, and came up with https://salsa.debian.org/terceiro/typeshed This seems to work, but there are still issues to solve, e.g. the licensing status of the stub_uploader repository¹, and generating a meaningful Provides: field. ¹ https://github.com/typeshed-internal/stub_uploader/issues/31 signature.asc Description: PGP signature
Re: mypy and typeshed
On Thu, Sep 30, 2021 at 04:29:20PM -0300, Antonio Terceiro wrote: > Maybe I didn't dedicate enough time for this, but I couldn't figure out > how the pypi packages are produced from the git repository. Knowing this > would help creating such typeshed package by means of some scripting > (not necessarily volunteering, will be happy if someone beats me to it). It turns out that this is done by this repository: https://github.com/typeshed-internal/stub_uploader signature.asc Description: PGP signature
Re: mypy and typeshed
On Thu, Sep 23, 2021 at 09:25:26AM +0200, Michael R. Crusoe wrote: > 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. Particularly, I try to develop all my Python work against Debian, and having a mypy that is broken by default without installing stuff that is not in the Debian archive is a major incovenience. > 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! Maybe I didn't dedicate enough time for this, but I couldn't figure out how the pypi packages are produced from the git repository. Knowing this would help creating such typeshed package by means of some scripting (not necessarily volunteering, will be happy if someone beats me to it). signature.asc Description: PGP signature
Re: mypy and typeshed
On Thu, Sep 23, 2021 at 5:51 AM Stuart Prescott 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,
mypy and typeshed
Hi Michael thanks for uploading the new version of mypy :) 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? 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? cheers Stuart -- Stuart Prescotthttp://www.nanonanonano.net/ stu...@nanonanonano.net Debian Developer http://www.debian.org/ stu...@debian.org GPG fingerprint90E2 D2C1 AD14 6A1B 7EBB 891D BBC1 7EBB 1396 F2F7
