Support stub-only packages?

[astrojuanlu]

When trying to use flit to build a PEP 561 stub-only package, I found two main blockers:

• flit requires that module is a valid identifier, which I think is not expected for these packages (to be named *-stubs)
• flit looks for a __init__.py, which is not there

I understand that perhaps you want flit to support only normal Python packages, but I still wanted to open this feature request just in case :)

[astrojuanlu]

(Related, but different, to #265)

[takluyver]

The PEP makes stub-only packages sound like a largely temporary workaround which shouldn't be needed longer term. Is that still the case, or are there a lot of stub-only packages which look likely to stick around indefinitely?

Is it actually a problem to have a __init__.py in a stub-only package? Glancing at the PEP, it doesn't seem like it mentions this, and I would normally take 'package' in a Python context to mean a directory with a __init__.py file.

[astrojuanlu]

These are good questions but I'd need an authoritative voice to answer them. I opened a thread in the Python discourse, hope you don't mind!

[astrojuanlu]

While the conversation in the thread develops, I made flit build work by:

• git mv foo-stubs foo_stubs
• echo -e '"""foo_stubs"""\n__version__ = "1.0.0"' > foo_stubs/__init__.py
• having a pyproject.toml with [build-system] and module, author, author-email, description-file in [tool.flit.metadata].

The only remaining problem is that if the package is called foo_stubs it doesn't get picked up by IDEs, and one would have to move it to foo-stubs. But from a practical point of view, having the __init__.py doesn't seem to be a problem.

[takluyver]

If putting an __init__.py in there is OK, and stub-only packages are something that are likely to stick around beyond temporary workarounds, then I think I'm OK with putting a special case in to allow <identifier>-stubs as a module name.

[MartinThoma]

Is there an update?