Upstream mousebender.simple for a simple repository API submodule?

[brettcannon]

Basically bring https://github.com/brettcannon/mousebender/blob/main/mousebender/simple.py here. @d3r3kk and myself would do the work.

If people like this idea we can discuss if the API works for people, what the submodule should be named (index? simple? simpleindex? repoapi? repo?), etc.

We do want to do https://github.com/brettcannon/mousebender/issues/48 which has a PR at https://github.com/brettcannon/mousebender/pull/51 that's still being discussed, but I figured we don't really need to wait for that in order to upstream the rest of it now.

[brettcannon]

Should the lack of comments signal no interest in this? Or no specific opinion on the matter and people are fine if I add this module?

[uranusjr]

Not strictly for or against the idea, but I wonder whether this is a good time to turn packaging into a namespace package. When there were only requirements, specifiers and version, it’s an obvious choice to bundle them together since a user will want all of them like 99% of the time. But now it’s increasingly more likely people would want only a subset of things. Since there are no top-level names under packaging, it’s perfect as a PEP 420 namespace package. And if we do that, adding a submodule would be almost no cost, since a user can simply choose to not install something they don’t want.

[brettcannon]

I have no specific objection. Would we make this more of a monorepo for all of the projects and the current packaging project an install-everything situation?

But do we think there are enough people who would want control over what is installed to warrant the overhead of becoming a namespace package? If people vendor then they can always leave out what they don't want.

[uranusjr]

Yeah I’m thinking about making this a monorepo that publishes multiple packages, with packaging simply depending on all of them, yes.

Edit: There will be backward incompatibilities though; currently there are some constants exposed on top-level packaging, and a PEP 420 namespace package cannot have those (not in a idiomatic way, at least), so we’ll either need to drop them or do some cleaver tricks to populate them at run-time.