[Python-ideas] PEP 561 v2 - Packaging Static Type Information

[Nick Coghlan]

On 13 September 2017 at 14:33, Ethan Smith <ethan at ethanhs.me> wrote:
> On Tue, Sep 12, 2017 at 8:30 PM, Nick Coghlan <ncoghlan at gmail.com> wrote:
>> There are a lot of packaging tools in use other than distutils, so I
>> don't think the distutils update proposal belongs in the PEP. Rather,
>> the PEP should focus on defining how type analysers should search for
>> typing information, and then updating packaging tools to help with
>> that can be treated as separate RFEs for each of the publishing tools
>> that people use (perhaps with a related task-oriented guide on
>> packaging.python.org)
>
>
> I think this makes a lot of sense. Would a description of the package
> metadata being queried suffice to be generic enough?

It would - a spec to say "Typecheckers should look for <x> to learn
<y>" and "Publishers should provide <x> to tell typecheckers <y>".

PEP 376 is the current definition of the installed package metadata,
so if you describe this idea in terms of *.dist-info/METADATA entries,
then folks will be able to translate that to the wheel archive format
and the various legacy install db formats.

>> I'm not clear on how this actually differs from the existing search
>> protocol in PEP 484, since step 3 is exactly what the
>> 'shared/typehints/pythonX.Y' directory is intended to cover.
>>
>> Is it just a matter allowing the use of "<name>-stubs" as the typehint
>> installation directory, since installing under a different package
>> name is easier to manage using existing publishing tools than
>> installing to a different target directory?
>
> Perhaps I could be clearer in the PEP text on this. The idea is that people
> can ship normal sdists (or what have you) and install those to the package
> installation directory. Then the type checkers would pick up `pkg-stub` when
> looking for `pkg` type information via the package API. This allows a third
> party to ship just *.pyi files in a package and install it as if it were the
> runtime package, but still be picked up by type checkers. This is different
> than using 'shared/typehints/pythonX.Y' because that directory cannot be
> queried by package resource APIs, and since no type checker implements PEP
> 484's method, I thought it would be better to have everything be unified
> under the same system of installing packages. So I suppose that is a rather
> long, yes. :)

OK, it wasn't clear to me that none of the current typecheckers
actually implement looking for extra stubs in
'shared/typehints/pythonX.Y' .

In that case, it makes a lot of sense to me to try to lower barriers
to adoption by switching to a scheme that's more consistent with the
way Python packaging and installation tools already work, and a simple
suffix-based shadow tree approach makes a lot of sense to me from the
packaging perspective (I'll leave it to the folks actually working on
mypy et al to say how the feel about this more decentralised approach
to managing 3rd party stubs).

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia