I’m going to try an experiment and explicitly open myself up to questions about my nomination for the PPC. You can ask here or see Frequently Asked Questions - Open Source by Brett Cannon for other ways you can ask me a question (public or private).
The reason I’m doing this is I want to lower the barrier for finding out whatever you want to know about my views on things that you would find important in deciding whether to (not) vote for me. As well, doing something similar to this for the SC has also come up and someone had to try it first, so why not me?
I want a universal binary to serve as a launcher/upgrader/whatever-er for Python across Windows/Mac/Linux.
Like PyManager maybe? I don’t know really.
Is this something the PPC would seek to get across the line and, perhaps, distributed wherever possible so getting the latest or arbitrary versions of Python are easier for all - but mostly newcomers to the language?
iirc you have something like this in a repo somewhere (py launcher?), but less offical.
So I think it depends on what the tool’s scope is. If it’s to install Python, then that probably falls under the SC since the builds would be coming from the CPython RM. But if the tool did stuff like pipx/uvx and/or supported inline script metadata, etc. then it gets murky. I want to see this happen, though, regardless of whose purview it falls under (see GitHub - python/prebuilt-cpython: Repository for discussing/planning prebuilt binaries of CPython · GitHub as the first step).
You can see my notes on all of this at Overview - Open Source by Brett Cannon , but basically I want to make it as easy as possible to run Python code (something all the workflow tools already do). Then if you need fancier features, go use e.g. Hatch.
How do you see the PPC’s role interacting with PyPI, given PyPI is operated by PSF staff, assisted by volunteers rather than something the PPC directly governs? Or maybe you think it should? Where would you draw the line between packaging policy guidance and PyPI’s own operational decisions?
PEP 772 leaves ‘establishing the Packaging Council and PyPA relationship’ to the inaugural council, and PyPA itself has never had real authority. Concretely, what should PyPA become: stay as-is, get formalized with real membership/governance, narrow down to just a project home + fiscal sponsorship umbrella, or get absorbed into the PPC’s standards role entirely?
I think it should stay as-is. It seems to work right now, so why try to change it? I think the folks who maintain PyPI should definitely be consulted on PEPs and such that would affect PyPI, but how it’s run is a PSF decision and I’m comfortable with that separation.
For me, I think the PPC should take over packaging.python.org in terms of direction and obviously updating the specifications. I think packaging.python.org would do well with a bit more of an opinionated direction as it’s often stuck in any progress when trying to make all the people happy all the time.
Otherwise I think the PPC should try and help PyPA projects get what they need, but otherwise let projects manage themselves. Ultimately I see the PPC managing the specs around packaging (as much as packaging.python.org lets them), acting as a touch point with groups that are not directly involved with packaging.python.org (e.g. conda and coordinating about things that make sense to be the same everywhere), and try to think long-term about stuff so we can try and hit bigger goals that otherwise would have been too big or iffy for someone to risk putting time into.
What role do you see the PPC playing in making contributing ideas to better packaging more inviting and easier for newcomers? Do you see PEPs as remaining to be the only process for packaging changes to happen?
It’s a key role. I think a lot of things we want to improve aren’t really controversial, but the overhead of getting them through
No. I think the PPC could choose to accept changes to specs directly and avoid going the PEP route for things that do not require a conversation that’s so long it needs to be recorded. But I also don’t see how to avoid something like PEPs for big changes (I’m not tied to PEPs specifically, but I’m also not aware of any other group coming up with an overall better solution, just variations).
It somewhat depends on what the PPC decides should be their mandate. But that’s probably the most important place I could help. The initial SC had grand plans to come up with a strategy for Python and help guide folks to tackle issues the SC thought could use some help. But then it quickly became apparent that just staying on top of conversations and PEPs took up a ton of time. Add in CoC issues and there is little time to plan where to go next.
So my advice to the PPC would be to keep the scope small and targeted, e.g. leave the PyPA projects to run themselves. Then try to lower the cost of changing the specs so it takes up less time (I think I’ve seen at least one other nominee suggest updates to a spec don’t need a PEP unless asked for, and that seems fair).
But I do think the PPC is in a position where trying to communicate where they would like to see things go is important. There are so many direct stakeholders with specific pain points to be resolved compared to the language where we are trying to improve things, but if the language didn’t change anymore it would probably be fine.
So that’s the quick summary. And even if I don’t make it on to the PPC I would still be happy to talk to them.
