Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://github.com/python/typeshed/issues/2491 below:

Explore building third party stubs as packages · Issue #2491 · python/typeshed · GitHub

This is an alternative to #2440 (disallowing third-party stubs). The idea is that typeshed remains/becomes a central repository for third-party stubs that are not bundled with the parent package, similar to DefinitelyTyped. In the future I expect type checkers will not want to bundle all third-party stubs for a variety of reasons, so third-party stubs would be distributed as separate PEP 561 stub-only packages, one per upstream package.

(I tried to integrate points raised there into this issue, especially those by @JukkaL in this comment.)

• Due to typeshed's tests, packages in typeshed will continue to work with the latests versions of mypy and pytype.
• Basic level of consistency and standards due to review by typeshed maintainers.
• Consistent naming scheme for third-party stubs packages, allowing users to just "pip install <guessed name>" and it will work when there are stubs.
• Tooling (like tests) is easier to manage as it can remain part of the typeshed package.
• Easier to contribute to stubs, since contributors don't need to learn the intricacies of multiple stubs projects.
• No need to start a separate project just to distribute stubs for a new package.

• Workload issues for typeshed maintainers.
• Typeshed maintainers will often not be familiar with the package for which pull requests are opened.
• Publishing stubs takes longer due to the necessary reviews.

What should the generated packages be called? @ethanhs's PEP 561 actually requires stubs-only package to be named <package>-stubs. typeshed could squat these names and release them (and remove the stubs) on the request of upstream maintainers. Alternatively, typeshed could add a common prefix or suffix (ts, typeshed) or in addition to or instead of the -stubs suffix. This would be in violation of PEP 561, so we'd need to get broader consensus to amend the PEP. My personal favorite would be <package>-ts.

To guarantee a fairly quick turnaround on stubs, to minimize work for publishing stubs, and to prevent all third-party stub packages to be updated whenever a new typeshed version is released, stubs for a specific third-party package should be published automatically when it changes.

• Add a generic setup-tp.py to typeshed that takes its package name from the directory it's in and uses the current date and time as version number.
• Amend the CI process for master only so that after a successful test run, for every third-party package that was changed since the last successful run, the following is done automatically:
  1. Copy setup-tp.py into the third-party module directory as setup.py.
  2. Build the package in that directory.
  3. Upload to pypi.

blueset, staticdev, hoefling and Garrett-R

RetroSearch is an open source project built by @garambo | Open a GitHub Issue

Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo

HTML: 3.2 | Encoding: UTF-8 | Version: 0.7.4