Skip to content

Type Hints #1095

Closed
Closed
@mdantonio

Description

@mdantonio

Hello,

I was looking for any type hints for GitPython, but I found nothing neither in the code nor in independent stub repositories.

Is there any plan to introduce type hinting?

Activity

Byron

Byron commented on Dec 22, 2020

@Byron
Member

I am absolutely open to receiving PRs adding type hints, and GitPython would be happy to host them directly in source.

Any amount of types would help and is appreciated, thus there is no need to add type hints everywhere at once.

Yobmod

Yobmod commented on Feb 18, 2021

@Yobmod
Contributor

I looked at starting to contribute type hints, but wanted to ask would it be feasible to drop support for python 3.4 (EOL 2 years ago)?

With 3.5+ type hints can be added directly to the code, but for 3.4 they would need to be in .pyi files, doubling the number of files and requiring they are kept in sync (AFAIK, 3.4 will give errors rather than ignore most inline type hints even though annotation syntax is possible)

Byron

Byron commented on Feb 19, 2021

@Byron
Member

@Yobmod Thanks for bringing this to my attention, and I would be glad to see type hints in code. Please feel free to submit a draft PR that starts out by dropping PY3.4 support to allow adding the first type hints in code. That one wouldn't have to be complete at all, but could lay the foundation for more PRs adding types in future.

Yobmod

Yobmod commented on Feb 24, 2021

@Yobmod
Contributor

I've put in a PR to drop python 3.4.
Planning to use Monkeytype to add initial types to the most user-facing files and see how that goes.

Yobmod

Yobmod commented on Feb 27, 2021

@Yobmod
Contributor

A plan:

  • Drop 3.4 (add 3.9)
    Final 3.4 release
    Monkeytype using test suite
    Add monkeytype.sqlite3 and mypy.ini to .gitignore
    Apply initial types to Repo/base & Repo/fun
    Add mypy.ini
    Add py.typed
    Appy initial types to git/*
    First typed release
    Appy initial types to index/*
    Appy initial types to refs/*
    Appy initial types to objects/*
    Increase mypy strictness
    Expand/Refine types (use overloads, Literals, TypedDicts etc)
    Make IterableList Generic & update throughout
    second typed release
    Drop 3.5 (add 3.10)
    Fix blocking issues caused by 3.5 compat
mdantonio

mdantonio commented on Feb 28, 2021

@mdantonio
Author

Thank for all the effort towards type hints! I am sorry I have not been able to contribute so far, I hope to be able to put some effort after the great initial start of @Yobmod

Yobmod

Yobmod commented on Feb 28, 2021

@Yobmod
Contributor

Thank for all the effort towards type hints! I am sorry I have not been able to contribute so far, I hope to be able to put some effort after the great initial start of @Yobmod

Thanks, Any help is always good :)

Branch for adding types is here: https://github.com/Yobmod/GitPython/tree/addtypes

Mypy-stubgen just typed everythin as Any, and Monkeytype has not been as useful as i hoped. If any wants to run it, commands are:

  • monkeytype run test/tstrunner.py
  • monkeytype list > mtype_filelist.txt
  • monkeytype stub git.cmd > git/cmd.pyi

But i'm mostly doing them by hand.

kasium

kasium commented on Jun 30, 2021

@kasium
Contributor

Hey, it seems that most of the code is typed, right? Would it be possible to include a "py.typed" file into the repo so that mypy can pick the types up?

Yobmod

Yobmod commented on Jun 30, 2021

@Yobmod
Contributor

Hey, it seems that most of the code is typed, right? Would it be possible to include a "py.typed" file into the repo so that mypy can pick the types up?

Hi, there already is one. Are you on the newest version?
Annotations showing up for me.

kasium

kasium commented on Jun 30, 2021

@kasium
Contributor

Yes I use the latest version. The py.typed file is not present in the tar.gz nor in the wheel - maybe that's the issue.
Mypy (also latest version) complains that no stub could be found

Yobmod

Yobmod commented on Jun 30, 2021

@Yobmod
Contributor

I've read up on some setuptools options, it seems that the package_data and include_package_data arguments are mutually exclusive. So setup.py is picking up the package_data only from the MANIFEST.INI and not from within the setup.include_package_data list.

I'll add py.typed to the manifest and hopefully that fixes it.

kasium

kasium commented on Jun 30, 2021

@kasium
Contributor

Great. thanks a lot

48 remaining items

kasium

kasium commented on Aug 2, 2021

@kasium
Contributor

So, I opened #1309.
Please note that gitpython says it's compatible with >= 3.6.0 but it's only compatible with > 3.6.1! See the PR for details.

Yobmod

Yobmod commented on Aug 2, 2021

@Yobmod
Contributor

Seems useful already!

So we have to decide:

  • Drop 3.6 now,

  • or i'll pull out NamedTuple defaults (there are only a couple of uses) for now.

(NoReturn and Deque are available in typing_extensions, so that can be easily fixed.)

I was planning to wait until 3.10 released to drop 3.6.
But I see it had it's final release this June and i have noticed big packages already dropping it (numpy and pandas did last year and therefore most of scientific packages).

Byron

Byron commented on Aug 2, 2021

@Byron
Member

Dropping py 3.6 seems like the path of least resistance.
I suggest to go with that.

gaborbernat

gaborbernat commented on Aug 2, 2021

@gaborbernat

If someone wants to change all the * imports to match __all__ for each module it will fix it, but otherwise have to wait for the bug to be fixed. Current workaround is if using --strict, also use --implicit-reexport.

See python/mypy#8754 (comment), seems this is not a bug in mypy, but a feature and the issue lies in this package, not the type checkers (both mypy and pyright seem to assume that implicit re-export is off).

Yobmod

Yobmod commented on Aug 2, 2021

@Yobmod
Contributor

If someone wants to change all the * imports to match __all__ for each module it will fix it, but otherwise have to wait for the bug to be fixed. Current workaround is if using --strict, also use --implicit-reexport.

See python/mypy#8754 (comment), seems this is not a bug in mypy, but a feature and the issue lies in this package, not the type checkers (both mypy and pyright seem to assume that implicit re-export is off).

Its fixable here, but there are 156 implicit-reexports errors if its activated in the codebase atm, so it wont be done for the next few releases unless someone volunteers.
I've added implicit_reexport = true to our settings, but I don't know if that will be overriden downstream?

kasium

kasium commented on Aug 11, 2021

@kasium
Contributor

Is there any update how you want to proceed with this?

Yobmod

Yobmod commented on Sep 9, 2021

@Yobmod
Contributor

@Byron

I think i've done everything I planned for the next release.
3.6 is dropped, and all reported errors in typing fixed and tested against an expanded test matrix. (Github actions only goes as early as 3.7.5 though).

Testpypi uploads fine (using 3.7.3), so ready to go!

Byron

Byron commented on Sep 10, 2021

@Byron
Member

Thanks a lot! Thanks to a 'hickup' this was ultimately released as https://pypi.org/project/GitPython/3.1.23/ .

unpinned this issue on Jan 7, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Relationships

    None yet

      Development

      No branches or pull requests

        Participants

        @Byron@adeandrade@gaborbernat@mdantonio@kasium

        Issue actions

          Type Hints · Issue #1095 · gitpython-developers/GitPython