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

Upstream mousebender.simple for a simple repository API submodule? #424

Open
brettcannon opened this issue Apr 27, 2021 · 4 comments
Open

Comments

@brettcannon
Copy link
Member

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 brettcannon/mousebender#48 which has a PR at brettcannon/mousebender#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
Copy link
Member Author

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
Copy link
Member

uranusjr commented Jun 20, 2021

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
Copy link
Member Author

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
Copy link
Member

uranusjr commented Jun 21, 2021

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.

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

No branches or pull requests

2 participants