-
Notifications
You must be signed in to change notification settings - Fork 296
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
refactor: Migrate to the flat layout #488
base: main
Are you sure you want to change the base?
Conversation
I will add `py.typed` after this PR is merged.
(I am not sure why "5 workflows awaiting approval" is not shown.) |
I plan to rebase the PR after the review. |
marking as draft because i think we need a larger discussion before making this kind of change (for example, i am not convinced but i havent thought about it too much, maybe i am missing an argument for (or against)) |
@kshramt I read through the referenced issue, but I don't get the context of why we would want a flat package hierarchy? Having all community packages in the |
@santi, thanks for the comment. I appreciate the neatness of the current structure but have observed some challenges, especially for those new to the unique packaging patterns. When I set out to integrate MyPy support, my initial expectation was straightforward: simply run Additionally, specific adjustments, such as those detailed in 507e466#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711R33 and 507e466#diff-50c86b7ed8ac2cf95bd48334961bf0530cdc77b5a56f852c5c61b89d735fd711R234, are rendered unnecessary with a transition to the flat layout. Migrating to this layout not only makes the project structure more intuitive for everyone involved but also minimizes maintenance overhead associated with tools' structural requirements. I believe that adopting the more common flat layout could make the project more accessible and easier to maintain. I'm genuinely interested in your perspective on this issue. Do you have any specific concerns with the flat layout, or are there other solutions you believe might be more effective? |
the part of the project under |
I understand the rationale behind segmentation for facilitating partial typing efforts. However, it's worth noting that the flexibility for partial typing can still be maintained within the flat layout. As outlined in https://peps.python.org/pep-0561/#packaging-type-information , package maintainers aiming to support type checking must include a If I interpret correctly, this implies that by placing a |
For distribution, according to python/typing#1429, a partially annotated package with the root |
Personally, I would argue that everything should be typed and failing to do so is a bug. At least in my books, a untyped library reflects badly on how I would judge the library nowadays (looking at confluent kafka...). |
I am with @kshramt on this. But I would prefer a src layout instead of flat layout. Doing so it more clear what is actually packages and prevents some problems testing the wrong package.... |
Hey all! Since I wrote the refactor to the current There is a very simple reason why it is I wish we had better automation and support from the TC staff (I'm only a volunteer myself like @alexanderankin) but this is what we've got for now. |
If this PR is accepted, I intend to follow up with another PR to add
py.typed
to address #305 .