Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Request: adding type hints and py.typed to setuptools_scm #501

Open
jamesbraza opened this issue Dec 6, 2020 · 13 comments
Open

Request: adding type hints and py.typed to setuptools_scm #501

jamesbraza opened this issue Dec 6, 2020 · 13 comments

Comments

@jamesbraza
Copy link
Contributor

As I am sure the setuptools_scm maintainers are aware:

  • Type hints were added in PEP 484 in Python 3.5
  • Python3 <= 3.4 is basically deprecated Python 2.7 hangs on by a thread elsewhere

I use setuptools_scm as part of some type checked code (via mypy). From what I have seen, setuptools_scm:

  • Isn't type hinted
  • Doesn't have the requisite py.typed marker file per PEP 561
  • Supports Python 2.7 and 3.4+, per the tox.ini file

There is a similar ticket for setuptools: pypa/setuptools#2345

Any thoughts on adding support for type hints?

Aside: I'm not sure how one can add type hints and maintain support for Python 2.7 and 3.4.


Workaround

In the meantime, I am adding the following to my setup.cfg section for mypy:

[mypy-setuptools_scm.*]
ignore_missing_imports = True
@RonnyPfannschmidt
Copy link
Contributor

Im happy to add typing after python 2.7 is dropped

Python 2.7 will be dropped when pip does

@tuukkamustonen
Copy link

Pip 21.0 dropped py2 support. This can be now done! 🥳

@RonnyPfannschmidt
Copy link
Contributor

python 2 support was dropped in version 6 of setuptools_scm

@RonnyPfannschmidt
Copy link
Contributor

i started adding some type hints, its still along way till py.typed tho

@ssbarnea
Copy link

@RonnyPfannschmidt Any chance to resume on that? Even partial types could help, we don't need 100% from start.

@RonnyPfannschmidt
Copy link
Contributor

There are some needed breaking changes after which it makes sense,

Im currently a bit stretched

@RonnyPfannschmidt
Copy link
Contributor

type annotations are added, the 8.x series will not export them yet

@jamesbraza
Copy link
Contributor Author

More out of curiosity, why add type annotations and then not export them? Is it just to test out type annotations for some time?

@RonnyPfannschmidt
Copy link
Contributor

As soon as they are exported,the number of actions one can take for refactoring that count as breaking change increase

The typing closure for the configuration,scm versions and version schemes is currently very fuzzy and locking it in for externals would be a major paint

@jamesbraza
Copy link
Contributor Author

Oh that makes sense, thank you for circling back! Appreciate the quick response too

@RonnyPfannschmidt
Copy link
Contributor

That being said, i Wish I wasn't quite as stretched so I could complete the work on this timely

@kasium
Copy link

kasium commented Apr 9, 2024

Just my 2 cent on this: As long as the API is stable, IMO it's fine if the type annotations change in an incompatible way. You could even see type annotation changes as fixes since the type annotation is then better as before and maybe even more correct 😄

@RonnyPfannschmidt
Copy link
Contributor

as im rather stretched in delivering certain refactorings i am hesitant to impose possile type anotation enforced breakage on downstreams, not that there arent many of them

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants