Skip to content

Missing py.typed for type checking? #57

Closed

Description

@gishor

What happens?

After upgrading from 1.3.2 to 1.4.0, mypy complains whenever we import duckdb.

The error message is of the form:

error: Skipping analyzing "duckdb": module is installed, but missing library stubs or py.typed marker [import-untyped]
error: Skipping analyzing "duckdb.typing": module is installed, but missing library stubs or py.typed marker  [import-untyped]

The .pyifiles moved from the duckdb-stubs folder to duckdb itself. This page says:

Package maintainers who wish to support type checking of their code MUST add a marker file named py.typed to their package supporting typing. This marker applies recursively: if a top-level package includes it, all its sub-packages MUST support type checking as well.

And:

For stub-only packages adding a py.typed marker is not needed since the name *-stubs is enough to indicate it is a source of typing information.

So is a py.typed file needed now with the new version?

To Reproduce

$ echo "import duckdb" > test.py

# Success with 1.3.2
$ pip install duckdb==1.3.2 > /dev/null && mypy test.py
Success: no issues found in 1 source file

# Error with 1.4.0
$ pip install duckdb==1.4.0 > /dev/null && mypy test.py
test.py:1: error: Skipping analyzing "duckdb": module is installed, but missing library stubs or py.typed marker  [import-untyped]
test.py:1: note: See https://mypy.readthedocs.io/en/stable/running_mypy.html#missing-imports
Found 1 error in 1 file (checked 1 source file)

# Adding py.typed fixes the issue
$ touch $(dirname $(python -c "import duckdb; print(duckdb.__file__)"))/py.typed
$ pip install duckdb==1.4.0 > /dev/null && mypy test.py
Success: no issues found in 1 source file

OS:

OSX

DuckDB Package Version:

1.3.2 and 1.4.0

Python Version:

3.13.7

Full Name:

Gishor Sivanrupan

Affiliation:

Exaforce

What is the latest build you tested with? If possible, we recommend testing with the latest nightly build.

I have tested with a stable release

Did you include all relevant data sets for reproducing the issue?

Not applicable - the reproduction does not require a data set

Did you include all code required to reproduce the issue?

  • Yes, I have

Did you include all relevant configuration to reproduce the issue?

  • Yes, I have

Activity

  1. added a commit that references this issue on Sep 16, 2025
    ea5793e
  2. evertlammerts commented on Sep 19, 2025

    @evertlammerts
    Member

    Before extracting to a dedicated repo, we published three top-level packages in the same distribution package. One of them was duckdb-stubs, which contained only the stub files. I hadn't realized that moving the stubs into the top-level package would make a difference, that was a clear miss on my end.

    Looking at the spec (and these easier to read docs by mypy) we have two options:

    1. publish the stubs in a separate package like we did before
    2. publish the stubs with the code itself, and include a py.typed file

    The spec says that shipping stubs with the code is preferred: "For package maintainers wishing to ship stub files containing all of their type information, it is preferred that the *.pyi stubs are alongside the corresponding *.py files." I'm looking into what works best for us right now. Our stubs were incomplete (I guess that's a bit of a euphemism) and the scripts that generated them hadn't been used for a while. This is not a bad moment to make some improvements.

  3. dangotbanned commented on Sep 21, 2025

    @dangotbanned
    1. publish the stubs in a separate package like we did before

    One benefit of this approach is it allows downstream projects to install just the stubs for type checking workflows.

    E.g, in narwhals we can do this for pandas and pyarrow, but duckdb is a full install.

    That being said, I've never had an issue installing duckdb 😅

  4. edgarrmondragon commented on Sep 21, 2025

    @edgarrmondragon

    FWIW pyarrow is having a discussion (apache/arrow#45919) that might result in them either publishing stubs along with the main package, or inlining types.

  5. added a commit that references this issue on Sep 22, 2025
  6. evertlammerts commented on Oct 2, 2025

    @evertlammerts
    Member

    I'm about to land a pretty involved PR that hopefully gets everybody's static type checkers, linters etc happy again. This will go into 1.4.1 which is set to release on Monday. I'll build a dev release once this is landed with a recent duckdb core dev release.

    @gishor @vyasr @leamingrad @rclement @KyleKing you've all tagged this issue. It's late days, but it would be useful if some of you can check whether your setups are going to be happy with these changes, so that you don't have to wait for another bugfix release. I'll post the package version here as soon as it's on pypi.

    Some notable / risky? changes that are worth evaluating when you test:

    • The stubs now reflect the internal (C++) modules that are imported in their public counterparts. After going back and forth a couple of times between shipping them in the duckdb package and a dedicated _duckdb-stubs package I went with the latter. They should get picked up.
    • The duckdb.typing and duckdb.functional modules are deprecated in favor of respectively duckdb.sqltypes and duckdb.func. I've moved all internal references (except in tests) so hopefully importing duckdb never accidentally shadows typing. Shadowing issues somehow seem to be more prominent now, at least in my IDE. I don't know why this is but it'd be good to know this doesn't get in anybody's way.
    • We now have explicit mypy config in pyproject.toml, which hopefully gets picked up by your type checkers.
    • There is now a py.typed file in the duckdb package.
  7. added a commit that references this issue on Oct 2, 2025
    89f2b8f
  8. evertlammerts commented on Oct 2, 2025

    @evertlammerts
    Member

    Use this version to verify: https://pypi.org/project/duckdb/1.4.1.dev135/. Feedback very welcome!

  9. rclement commented on Oct 3, 2025

    @rclement

    Thanks @evertlammerts for issuing a dev release with a fix so quickly!
    On my side, the fix is working (simply using mypy --strict).
    I have a draft PR with explicit usage of 1.4.1.dev135: datalpia/laketower#126

  10. gishor commented on Oct 3, 2025

    @gishor
    Author

    The fix is also working on our codebase, thanks @evertlammerts!

  11. KyleKing commented on Oct 3, 2025

    @KyleKing

    Ditto, thanks for prioritizing this patch!

  12. added a commit that references this issue on Oct 3, 2025
  13. vyasr commented on Oct 6, 2025

    @vyasr

    I verified this as well on the polars-benchmark repository where I originally found and tagged this issue. PR to reenable is pola-rs/polars-benchmark#175 once 1.4.1 is released. Thanks for the fix!

  14. evertlammerts commented on Oct 7, 2025

    @evertlammerts
    Member

    1.4.1 just released: https://pypi.org/project/duckdb/1.4.1/

    Thanks for the help all!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions