Post
I think #Python packaging drives most people insane because they implicitly think "packaging" and "deployment" are the same thing.
Python packaging is a process for producing an intermediary artifact that can be consumed by Python programmers and organized according to community rules.
Python *deployment* does not really exist. You deploy to a platform, not a programming language. Which is double-maddening: Linux, the place where most people think they want to deploy, *also* isn't a platform.
@glyph A related problem is that Python packaging has two distinct modes (libraries and scripts) that often use the same "packaging tools" but with very different intended outcomes.
@glyph tbh pip on linux telling me to go break my computer instead of installing packages has mostly trained me out of thinking pip is useful for distributing software to normal users
@aeva yeah pip is not for that, for sure. although usually what pip is telling you to do is to _not_ break your computer, since "installing software (in the global namespace)" and "breaking your computer" are isomorphic concepts
@aeva I may not be caught up on the latest wreckage of pip on linux though, what in particular does it tell you these days?
@glyph It's further complicated by the fact that what you described is a programmer's view of what packaging is. Other parties have different views on the subject, especially the actual packagers.
@glyph I gave up on python for this reason.
I can do go install host/blah/project@version and it just works for loads of go projects. I can include projects simply and vendor them if I want. It all gets out of my way and I can work on what I actually need to work on.
Heck, even perl was easier. Python packaging is, quite frankly, inexcusable at this point.
@lyda you've misunderstood what I am saying, then. We all have our own expertise. I can reliably get just about any python project to work on any system under my control via 'pipx run' or 'uvx', but my attempts to use go and rust routinely blow up on some FFI shenanigans. Personally, I find Python provides loads of tools to relieve the user of native build and integration issues 95% of the time, whereas the second you touch cgo you are hip-deep in the swamp of infinite misery
Python packaging is a *prerequisite* to deployment, but it's only one of the prerequisites. The other, gigantic, implicit prerequisite is cobbling together your own platformoid out of Linux and a hundred other tools, which are *probably*, *mostly* the same as a whole bunch of other people deploying to a similar platformoid and calling it "Linux" (or "Ubuntu" or "Docker" or "Kubernetes" or something). But every one of a thousand different details could differ. It *probably* doesn't! But it might.
@glyph I ran into a gotcha today in deploying one of my server-side applications on top of Docker. Granted, this was a Java application, not Python, running on a recent JDK (21 I think) on Ubuntu 24.04. I forgot to set LANG to C.UTF-8, and as a result, the Java standard library threw an exception when given a filename with a non-ASCII character in it.
Your other options? macOS and iOS *are* platforms, but the vast majority of community knowledge of how to deploy to them involves deploying to the decrepit UNIX emulator buried in macOS, and giving up entirely on iOS. The first-party tools for properly deploying to these platforms are restrictive, weird, buggy, slow, and encumbered with a bunch of corporate ideology which heavily conflicts with the intellectual heritage of Python, so most Pythonistas (who mostly want Linux anyway) ignore it.
@phildini is anything here incorrect? :)
@glyph untrue? debatable. Unclear? certainly.
Reading it over 3 times, I _think_ you meant "Pythonistas ignore the first party tooling", which, yes, fair, everyone should.
If what you _meant_ is "Pythonistas ignore the platform of macOS and iOS", I have some CPython commits and a PyCon keynote to I can helpfully link you too
@glyph maybe Python needs something equivalent to Expo. A tool that is maintained with the purpose of creating compatible artifacts than can be published to iOS / MacOS / Android
@taulant https://beeware.org is that tool with the appropriately broad ambition to actually get the ecosystem into a good place eventually, but the surface area of the problem is like an infinite fractal. It's getting there, though.
Windows is barely a platform, one which even Microsoft seems keen to slowly destroy. It's comparatively "easy" to deploy to as compared to macOS, because of its atrocious security posture (mostly no need for integrity checking of any kind, so you can skip all the faff with certificates). But Windows is a platform which is very easy to pollute with implicit dependencies, and verifying that your artifact will work on someone *else's* computer mostly means buying a second computer for testing
> buying a second computer for testing
Is there a specific reason you said buying a second computer rather than creating a VM?
@matt making a VM that you can reliably test on is functionally buying all the resources you'd need for a second computer and then smooshing it together with your first computer for slightly more streamlined logistics :). but, for example, I use windows VMs to test on, and if I wanted to actually ship something commercially supportable for enterprises, I'd need a separate physical x86_64 machine because the aarch64 emulation leaves a bunch of potential failure points untested
@glyph Oh, hadn't thought about the extra wrinkles of testing on an ARM64 host.
@matt not to mention that there are many genres of windows software (disproportionate to, for example, web software) where you need a machine with a physical Intel GPU, a physical NVIDIA GPU, and a physical AMD GPU, and maybe an AMD CPU too. In my experience the software differences on Windows with these different configurations are bigger and nastier than mac / linux with different hardware, due to vendor-specific drivers
@glyph “what’s the name of this routine?” “the containerocrats!”
@luis_in_brief containers are also necessary but not sufficient :). or… not necessary, exactly, but with "native" packaging you can't ignore *any* of Linux's deficiencies as a platform, but with container images you can ignore like… 70-80% of those deficiencies. Except most people just build an image and then think "job done!"
@luis_in_brief my favorite "Oh No Baby! What Is You Doin???" pattern is the one where you make a docker image and then you make a systemd unit that runs 'docker run'. I hope that this has died out, I haven't seen it for a few years, but I suspect not
All of these platforms have a wide common surface area for _executing_ code, but properly _deploying_ code (getting it on your PATH, making an app icon show up, talking to the system secrets store, acquiring relevant permissions for networking, automatically starting up, automatically shutting down) are wildly different. So, once again, we have developed a culture of flinching away from the pain and just assuming a sysadmin will open a terminal window and type "python run_program.py"
@glyph by coincidence, not twenty minutes ago I read https://nesbitt.io/2026/01/27/the-c-shaped-hole-in-package-management.html
It has a different but related notional topic; if you haven't already seen it, you might find it interesting.
What makes a "platform" is a set of strict guarantees about what will be present, that your application can rely on, and what format your application needs to be presented to the user in. A "platform" is a description of a boundary between your artifact (not just your program!) and the system which will absorb that artifact. "Linux" is not a platform not merely because "it's just a kernel" but because the shared idioms even between different desktop distros do not encompass such guarantees
@glyph this aligns well with something I was thinking about last night. Someone was splitting hairs about "actually Linux is just a kernel GNU/Linux is the operating system", but there's no operating system called GNU/Linux that you can just install on your computer, it's a family of operating systems that have names like "Debian" and "GUIX" that are mutually incompatible with one another, which makes "porting to Linux" a nightmare.
There *might* be an emergent platform that's something like "Linux-wayland-dbus-systemd-flatpak" but trying to define the boundaries and properties of such a thing is an incredibly labor-intensive project. Or maybe "Linux-6-docker-ipv4-no-firewall". Perhaps somewhat narrower than the earlier example, but still *shockingly* fraught with weird failure modes and undocumented inconsistencies between providers
@glyph this is one of the reasons I moved into JavaScript for stuff I want non-programmers to ever use. "Web browser" is the ultimate platform, assuming you can stomach its incredible constraints.
This is a bonfire demo instance for testing purposes. This is not a production site. There are no backups for now. Data, including profiles may be wiped without notice. No service or other guarantees expressed or implied.
