The fact that it's 2023 and I STILL can't easily build a static distributable Python CLI is just an embarassing indictment of our whole community IMO.

My answer to "how do I build a distributable CLI in Python" today is "use Go or Rust".

And before you ask "have you seen …" — yes. Yes I have. I've tried everything in this space over the last TWENTY YEARS and nothing even comes close to the DX offered by Go or Rust.

@jacob It won’t be solved until Python core makes it a priority. We have been dancing around the edges of solving the problem for decades with third party approaches. This is a battery that is most certainly not included.

@jonathan I don’t think they ever will. Python core is sort of institutionally incapable of understand how hard getting a working Python environment is for normal people. Individual members of that team sure, but almost definitionally most folks on that team are experienced enough to have completely forgotten what a high bar that is. For them “just pip install cli” is super easy, I think they genuinely don’t understand what the fuss is about.

@jacob @jonathan I think another angle to it is Python core handed off / left packaging to a completely different group of people literally decades ago, and this is typically viewed as a "packaging thing". So to bring it into core could be viewed as a power shift/grab at this point.

I'm not saying that's necessary a bad shift, but I think it expands beyond the core team at this point.

@brettcannon @jonathan the options are power grab or shitty UX forever IMO.

@jacob @brettcannon @jonathan I think there is a lot of daylight between where we are and where python core *must* get involved. The issue is that huge amounts of effort have been spent to get things into and out of PyPI and that experience is smooth. If similar amounts of effort were spent to get things uploadable to e.g. a custom Homebrew tap, there could be an excellent third-party DX. Maybe a single-binary builder could be a part of that, but it's a mostly-irrelevant implementation detail.

@glyph @jacob @brettcannon Its been decades leaving this problem unsolved in core. The community hasn’t solved it. Not sure where that daylight is?

@jonathan @jacob @brettcannon by "daylight" I just mean "distance". There are a ton of things that third party tools could do. The issue is not that the tools are third party; the issue is that the tools are broken. Get pyinstaller or pyoxidizer or whatever tool you like and try to make it do something out of the box, I guarantee you'll see an inscrutable traceback along the way at least once

@jonathan @jacob @brettcannon there *is* a point of diminishing returns where a well-functioning tool that works super well just can't do any better until it's included in the core experience and integrated into every python install, but we are worlds away from that point

@glyph @jacob @brettcannon I understand your point. Not sure I 100% agree, but it is a fair point.

I am not familiar enough with the implementations that exist to understand *why* the experience is lousy. Are there features in core that could be added that fall short of being a total solution but would enable third party tools to be more successful? Or is it exclusively a community failure?

@jonathan @jacob @brettcannon There are a lot of different ways to attack the problem, and it's not even a failure, so much as a … lack of success. In any conversation about packaging I always highlight the successes because a lot of people have volunteered a lot of time to solve specific, even difficult problems, and often solve them pretty well, but the incentive structure around the whole problem space makes it difficult to motivate folks to work on a holistic solution.

@jonathan @jacob @brettcannon I guess here's my top-line view on the whole mess:

It feels like we have to do something grand and sweeping and fundamentally architectural to address this problem space. That feels exciting. But what we really need to do as a community is to just do the very boring long-term scut work of finding a tool that almost works, report a zillion bugs on it, write better docs for it, and smooth out the UX one horrible edge-case at a time.

@glyph @jonathan @brettcannon that's what I mean about social stuff tho. The Python community is famously bad at coalescing around anything that doesn't ship with Python. (And even things that DO ship with Python don't always catch on, as you've said). My take is that without a "blessing", there won't ever be critical mass behind any one tool.

/me looks pointedly at pipenv, poetry, twine, pip-tools, conda, .......

Follow

@jacob @glyph @jonathan @brettcannon pip didn’t come from core.

pytest was in active competition with unittest and still isn’t in core.

Virtualenv was ubiquitous before venv was created, and I get the impression that it is still more popular.

Sign in to participate in the conversation
Qoto Mastodon

QOTO: Question Others to Teach Ourselves
An inclusive, Academic Freedom, instance
All cultures welcome.
Hate speech and harassment strictly forbidden.