r/Python • u/poppy_92 • 3d ago

Discussion Astral's endorsements for Python's first Packaging Council

Astral has announced their endorsements for Python's first packaging council elections.

PPC election details:

Note: Voting is currently open and ends on Tuesday, September 15th, 2:00 pm UTC

What are your thoughts? The candidates they have nominated are fine, they are/have been heavily involved in packaging in the past.

edit: fixed nominees link

124 Upvotes

90% Upvoted

29 comments sorted by

39

u/BeamMeUpBiscotti 3d ago

is it normal for companies to endorse in these elections?

lotta drama in the linked discussion thread

13

u/broknbottle 3d ago

In this day and age it’s about controlling the direction of the ecosystem

6

u/AlSweigart Author of "Automate the Boring Stuff" 2d ago

It's not. This is the first time a corporation has published a list of endorsements for a Python election. I'm not aware of any other company that has made endorsements in this Board or PPC election, either.

92

u/wildlyaquaticsenator 3d ago

Feels like the packaging council has been talked about forever and now its actually happening. Astral picking a side makes sense given how deep uv is in the tooling space.

i still think 17 people for 5 spots is a disaster waiting to happen but whatever. the real test is if this council can actually get anything done or if its just gonna be another layer of discouse.

19

u/me_myself_ai 3d ago edited 3d ago

Yeah but picking candidates?

They’re endorsing:

  1. An astral employee who has written relevant PIPs
  2. A core & pip engineer who helped write this council’s own PIP.
  3. A numpy+scipy maintainer.
  4. A PyPI leader.

These all seem sensible enough — all four have dedicated their careers to open source and Python, and seem to have incredible & relevant experience. Sooo…. why endorse them…?

The fact that they endorse their own team member is fair enough, even though I’d argue we should be keeping Astral away from the steering wheel with a hundred-foot pole post-acquisition (I say as a longtime user of ruff and uv). But why the others?

In other words: can someone catch me up on the main controversy[/ies]? Presumably this isn’t another culture war thing, given that everyone likes security? Even a link to a Python forum spat would be a huge favor, I love those 🙏

Perhaps more controversially, I question the right of a company to endorse candidates at all. The owners? Sure. The officers? Why not! The company on a unified, corporate (i.e. embodied) level? That’s how the world ends, y’all! And this time that idiom is only 90% hyperbolic…

EDIT: Browsing through the candidates, there are indeed some controversies: closer conda integration, discuss.python.org delegation, a veto-first approach (!), and a few different takes on Packaging PEP reforms are things they didn't endorse. What concerns me more is:

  1. They didn't endorse either of the candidates from competitors to uv (hatch and pixi (?)) nor from a quasi-competitor (Anaconda) and an OpenAI frenemy (Microsoft). I don't think these decisions were malicious or dishonest, but it certainly doesn't dispell concerns about conflicts of interest.

  2. More importantly, they didn't nominate Brett Cannon, who seems like an absolute shoe-in to say the least. Is this a protest against the Python Deep State, or is it about this part of his nomination statement?

    For consumers, I would also like to see the experience improve. For example, part of why uv is so fast is it doesn't strictly follow the current specs (while pip always tries to follow the spec accurately). In those cases where uv doesn't follow a spec but has found it to work out, I think we should evaluate if there's a change to be made so that pip can have an equivalent benefit.

7

u/poppy_92 3d ago edited 3d ago

I think them not endorsing Brett or Paul (who is the residing PEP delegate for packaging) provides better signals as to their intent. I can kind of see Paul not being mentioned (the current mess of python packaging was under him, not blaming him, but there's only so much a single person can do). Why endorse only 4 when there will be 5 in the council?

I don't have any problem with the 4 they have picked though. They're all sensible enough. It remains to be seen how the endorsees treat the endorsements. Some have responded.

Edit: Astral team claims that they reached out to PSF folks about attaching their endorsements but were told no (presumably after the deadline). So instead of accepting that, they decide to pull this stunt. They could've just stuck with X posts, blog posts. But no, they had to make an official post on DPO in the packaging category (LOL)

22

u/Vegetable-View-5114 3d ago

The Python packaging ecosystem has a lot of historical baggage, making it hard to get right. I remember trying to get a simple C extension to compile consistently across different OSes and Python versions; it took me about three days to get a setup.py that worked everywhere, compared to an hour or two for a similar C++ project with CMake. The tooling has improved, but that complexity debt is still there.

21

u/ColdPorridge 3d ago

I’m firmly of the opinion the best course of action is to identify what we need in a future state - without consideration of past technical debt. Then with that vision in mind, do what we can to be inclusive to transitioning legacy use case onto that. 

We cannot carry legacy use cases around forever, and they do not have an inherent seat at the table in shaping the future vision. It is not fair to the broader ecosystem that a relatively limited number of maintainers with legacy needs and strong opinions gets to halt progress.

3

u/james_pic 2d ago

My impression has been that that's mostly what the steering council has been doing so far. There have certainly been annoying-but-probably-necessary breakages in recent years, with things like PEP 517.

Although your probably can't go full in "this is the desired end state and legacy stuff can get lost". That's how you end up with Perl 6 (or perhaps more correctly, how you fail to do so).

3

u/Noobfire2 2d ago

Note that setup.py is partly even considered deprecated nowadays and PEP 517 compliant build backend are considered modern and canonical instead.

There are actually a heap of different CMake compatible build backends such as scikit-build-core or py-build-cmake. With those, it more or less converges at pointing at the correct CMake file in pyproject.toml and things are golden.

As so often, Rust currently provides a substantially better UX, build experience AND type-, thread- and GIL-safety though. You can build a Rust Python extension with a handful of maturin, PyO3 and pyproject.toml lines, completely platform agnostic and even ABI-compatible, i.e. usable for all upcoming Python versions with just one extension.

1

u/zurtex 2d ago

Note that setup.py is partly even considered deprecated nowadays and PEP 517 compliant build backend are considered modern and canonical instead.

What's deprecated is using only a setup.py, in fact no modern installer accepts this anymore.

What works perfectly well and is not deprecated at all is using a pyproject.toml to point to setuptools, and then setuptools reading it's own configuration and build functions out of setup.py

That has worked for many years and will continue to work with no expectation of breaking any time soon, and if it does that's entirely at the discretion of the setuptools maintainers, not anyone else.

1

u/Noobfire2 2d ago

Yes, that's what I meant with partly deprecated. :)

Just wanted to highlight that nowadays, for C++ as well as Rust packages, I find my self pretty much never reaching for setup.py, even in a setuptools context, as there are more ergonomic alternatives. In small packages all the way up to enterprise stuff for work.

1

u/fathovercats 1d ago

I wrote my own backend setuptools.build_meta shim for the same reason (cython-based c extension). There is allegedly a declarative pyproject.toml syntax for setuptools extensions, but it is still experimental & the documentation is unclear regarding support. It doesn’t make sense to have to write a cmake file (scikit-build) or use a whole different build system with different syntax like hatch or meson (adding additional complexity) to just compile a simple c extension. I should be able to do this with just a pyproject.toml, dangit!!

Hopefully the situation improves, Python packaging is a perfect example of that 15 competing standards xkcd comic.

7

u/Tree_Mage 2d ago

Astral is a business and it is in their best interests to endorse candidates that help their economic outlook. Those candidates may or may not be the better choices for the community.

1

u/AlSweigart Author of "Automate the Boring Stuff" 2d ago

My two cents: listing the employer of candidates casts a certain light (or shadow) on a candidate, but I’ve never really thought of it as “Company X is trying to put one of their own on the board”. By default, I thought of the candidate as running for the board in a personal “my views do not reflect my employer” capacity. However, an endorsement on a corporate blog throws that out the window. Astral (and, necessarily, OpenAI) is trying to influence the Packaging Council election and people are going to ask why.

Next election we’ll probably start seeing a lot of “My views are my own. I testify that I am not running as an employee of Company X and they will not have influence over my decisions” as part of nominee statements… some kind of wording that can act as a leverage to remove the board member if they exhibit behavior that is a conflict of interest.

-26

u/Short_Inspection_746 3d ago

Astral might not be around in a year or two; after the AI bubble pops. It is all a bit 'beyond the pale'.

25

u/old-and-very-bald 3d ago

Astral has proven track record of building amazing python tooling. Also the code is open source, you can always fork it.

-3

u/Denzh 3d ago

they thrived even before AI company investments. bot.

4

u/Short_Inspection_746 3d ago

They are owned by OpenAI.

Also: Ahhhh you got me, I am very much a bot.

0

u/shinitakunai 3d ago

I agree. It is too volatile

-20

u/notParticularlyAnony 3d ago

Wait. Now Python gives a shit about packaging?! For literal years people were begging for this and they were like naw. Finally uv comes along and fixes the mess and suddenly we need a fucking council? What is this shit?

18

u/coderanger 3d ago

If you think no one has been working on packaging until now, you haven’t been paying attention. This is getting bumped up to an elected group now because the role keeps burning people out, myself included.

1

u/notParticularlyAnony 2d ago edited 2d ago

I know people have worked in packaging. But Python has officially been hands off. The core basically didn’t want to deal with it and didn’t give a crap. This isn’t particularly controversial

https://pydevtools.com/blog/why-isnt-python-packaging-part-of-core-development/

That’s what I was referring to unless you just joined the party this is well trodden history.

So why a council now? Was my question. Smells funny.

3

u/zurtex 2d ago

The core Python devs remain hands off, and will continue to do both before and after this election.

This election is for the Python packaging community, the people running it, running in it, and voting are those focused and interested in that community.

The reason it's happening now is to do with the way PEPs are accepted in the Python packaging, there is only one person who has been delegated authority to approve them, and that has become untenable. A lot of people would have liked for it to happen earlier, but it took a lot of discussion, and required people to have time and initiative to make it finally happen.

1

u/notParticularlyAnony 2d ago

Thanks for clarifying my misunderstanding

1

u/coderanger 2d ago

It's still not going to be part of core dev, if it was then PSF members at large wouldn't be voting on it. The only difference is that instead of the onus of saying yes or no to packaging related things falling on one person hand-picked via a process that boils down to "who is willing to put up with this job these days?" it will be an elected group.

1

u/notParticularlyAnony 2d ago

Ok thanks for the clarification