{"action":"created","issue":{"url":"https://api.github.com/repos/python/typeshed/issues/2440","repository_url":"https://api.github.com/repos/python/typeshed","labels_url":"https://api.github.com/repos/python/typeshed/issues/2440/labels{/name}","comments_url":"https://api.github.com/repos/python/typeshed/issues/2440/comments","events_url":"https://api.github.com/repos/python/typeshed/issues/2440/events","html_url":"https://github.com/python/typeshed/issues/2440","id":358686521,"node_id":"MDU6SXNzdWUzNTg2ODY1MjE=","number":2440,"title":"Should we accept new thirdparty stubs?","user":{"login":"srittau","id":52799,"node_id":"MDQ6VXNlcjUyNzk5","avatar_url":"https://avatars3.githubusercontent.com/u/52799?v=4","gravatar_id":"","url":"https://api.github.com/users/srittau","html_url":"https://github.com/srittau","followers_url":"https://api.github.com/users/srittau/followers","following_url":"https://api.github.com/users/srittau/following{/other_user}","gists_url":"https://api.github.com/users/srittau/gists{/gist_id}","starred_url":"https://api.github.com/users/srittau/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/srittau/subscriptions","organizations_url":"https://api.github.com/users/srittau/orgs","repos_url":"https://api.github.com/users/srittau/repos","events_url":"https://api.github.com/users/srittau/events{/privacy}","received_events_url":"https://api.github.com/users/srittau/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"assignees":[],"milestone":null,"comments":10,"created_at":"2018-09-10T15:54:10Z","updated_at":"2018-09-24T11:03:55Z","closed_at":null,"author_association":"COLLABORATOR","body":"Now that PEP 561 is supported by mypy I wonder whether we should accept new third party stubs into typeshed. Personally, I think we should steer those contributions to either be included into the parent package or to be distributed as a separate stubs package. This means that the people who actually care about those stubs (i.e. the submitters) can update the stubs more easily without having to go through the typeshed maintainers.\r\n\r\nMaybe we could also offer a kind of \"review service\" (as time allows) for getting those packages off the ground?\r\n"},"comment":{"url":"https://api.github.com/repos/python/typeshed/issues/comments/423939393","html_url":"https://github.com/python/typeshed/issues/2440#issuecomment-423939393","issue_url":"https://api.github.com/repos/python/typeshed/issues/2440","id":423939393,"node_id":"MDEyOklzc3VlQ29tbWVudDQyMzkzOTM5Mw==","user":{"login":"JukkaL","id":1107911,"node_id":"MDQ6VXNlcjExMDc5MTE=","avatar_url":"https://avatars2.githubusercontent.com/u/1107911?v=4","gravatar_id":"","url":"https://api.github.com/users/JukkaL","html_url":"https://github.com/JukkaL","followers_url":"https://api.github.com/users/JukkaL/followers","following_url":"https://api.github.com/users/JukkaL/following{/other_user}","gists_url":"https://api.github.com/users/JukkaL/gists{/gist_id}","starred_url":"https://api.github.com/users/JukkaL/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/JukkaL/subscriptions","organizations_url":"https://api.github.com/users/JukkaL/orgs","repos_url":"https://api.github.com/users/JukkaL/repos","events_url":"https://api.github.com/users/JukkaL/events{/privacy}","received_events_url":"https://api.github.com/users/JukkaL/received_events","type":"User","site_admin":false},"created_at":"2018-09-24T11:03:55Z","updated_at":"2018-09-24T11:03:55Z","author_association":"CONTRIBUTOR","body":"All in all, I basically agree with most points made by @bluetech.\r\n\r\nHere is some reasoning:\r\n* I worry that separately maintained stubs will get out of date after a while, or even stop working with the most recent version of mypy (or pytype, etc.). \r\n* If many packages are not interested in bundling type annotations, there could be hundreds (or even thousands) of separately maintained stub packages, each potentially with a unique contributor agreement, contributor documentation, code review process, style conventions, testing/QA approach, and release policy (or lack thereof). This raises the bar for making a contribution (@bluetech also raised this point).\r\n* Finding the right stub package can become a pain, since there can be multiple competing stub packages (say, forks of stale stub projects). \r\n* Some stub packages for less popular modules could be hard to find, especially if the package has a generic name that results in bogus Google results. \r\n* Setting up a new GitHub project for just a set of stubs for some package seems like a lot of friction. We can make it easier by providing templates, but the point still stands.\r\n\r\nI think that we should try to learn from DefinitelyTyped -- they have ~20x the number of commits compared to typeshed, so their model appears to scale well. Here are some things that I was quickly able to learn and that we might want to adopt in some form:\r\n\r\n1. They include thousands of third party packages in a single repository (and this seems to work well for them).\r\n2. They automatically release new type packages from github master.\r\n3. They allow installing types for a single package from the repository (as mentioned by @bluetech).\r\n4. Their [readme](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/README.md) explains how to install types and how contribute new types, in quite a lot of detail. The latter could help attract more contributors.\r\n5. They support writing tests for type definitions and explain this in their readme. Many tests seem pretty simple ([example](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/activedirectory2/activedirectory2-tests.ts) and [another example](https://github.com/DefinitelyTyped/DefinitelyTyped/blob/master/types/angular-gridster/angular-gridster-tests.ts)) but they may still be very helpful, as the reviewers can't be expected to be experts on every single package there is.\r\n2. They have a [search engine](https://microsoft.github.io/TypeSearch/) for type definitions.\r\n\r\nPackaging stubs seems like a problem for us. We could have a single monolithic typeshed package as we currently have, but this approach has issues:\r\n\r\n1. If there will eventually be thousands of packages, the package will be huge.\r\n2. Updates to newer typeshed versions can be painful, since it will be hard/impossible to pin the stub version for some package, in case the most recent version has some problem or there is a non-backward-compatible API change.\r\n\r\nMaybe we could somehow automatically generate a separate PyPI package for each new contributed package stub? Or we could have a script that makes this easy to do, even it requires some manual work. We could automatically generate a version number from the last modified date.\r\n\r\nThere is also the issues of needing to ask for permission from the package maintainers. This creates some friction. We could work around this by proactively asking for permission from the owners of the top 500 most popular packages on PyPI, for example, and making that list prominently visible somewhere."}}
{"actor":{"display_login":"JukkaL"}}