[objectified]

At first I was excited to see that a new tool would solve the Python "packaging" problem. But upon further reading, I realized that this was about _package management_, not so much about packaging a Python application that I've built.

Personally I haven't had many problems with package management in Python. While the ecosystem has some shortcomings (no namespaces!), pip generally works just fine for me.

What really annoys me about Python, is the fact that I cannot easily wrap my application in an executable and ship it somewhere. More often than not, I see git clones and virtualenv creation being done in production, often requiring more connectivity than needed on the target server, and dev dependencies being present on the OS. All in all, that's a horrible idea from a security viewpoint. Until that problem is fixed, I'll prefer different languages for anything that requires some sort of end user/production deployment.

[the_mitsuhiko]

> What really annoys me about Python, is the fact that I cannot easily wrap my application in an executable and ship it somewhere.

You are not wrong, but let's unpack this. What you're saying is that there is a need to make it easy for another person to run your application. What is needed for that? Well you need a way for the application to make its way to the user and to find some Python there and for that process to be transparent to the user.

That's one of the reasons why I wanted Rye (and uv does the same) to be able to install Python and not in a way where it fucks up your system in the process.

The evolved version of this is to make the whole thing including uv be a thing you can do automatically. You can even today already (if you want to go nuts) have a fully curl to bash installer that installs uv/rye and your app into a temporary location just for your app and never break your user's system.

It would be nice to eventually make that process entire transparent and not require network access, to come with a .msi for windows etc. However the per-requisite for this is that a tool like uv can arbitrarily place a pre-compiled Python and all the dependencies that you need at the right location for the platform of your user.

The cherry on the top that uv could deliver at one point is that fully packaged thing and it will be very nice. But even prior to this, building a command line tool with Python today will no longer be an awful experience for your users which I think is a good first step. Either via uvx or if you want you can hide uv entirely away.

[rtpg]

To put a finer point on this idea, even if one could be against even this idea of an “installation flow”, work done to improve uv or rye would also likely flow into alternative strategies.

The more we invest into all of this and get it right in at least one way, the easier it will be for alternatives (like pyoxidizer!) to also “just work”. At least that’s my belief.

There are tactical reasons to focus on one strategy, and even if it’s not your favorite… everything being compatible with _something_ is good!

[the_mitsuhiko]

Exactly. And in this particular case pyoxidizer and the work that went into it originally in many ways gave birth to parts of it. The python standalone builds were what made me publish Rye because there was something out there that had traction and a dedicated person to make it work.

Prior to it, i had my own version of Rye for myself but I only had Python builds that I made for myself and computers I had. Critical mass is important and all these projects can feed into each other.

Before Rye, uv, and pyoxidizer there was little community demand for the standalone python builds or the concept behind it. That has dramatically changed in the last 24 months and I have seen even commercial companies switch over to these builds. This is important progress and it _will_ greatly help making self contained and redistributable Python programs a reality.

[aragilar]

It depends where and what you are trying to install, but generally for every sensible deployment target there's a tool (sometime more than one) which handles building a installable binary for that target (e.g. an OS specific installer). There's now even tooling to deploy to unusual places such as Android or iOS or in the browser. Naturally in some cases specific packages won't work on specific targets, but because there are standard interfaces if the code is capable of being run somewhere, the tooling for that target should be able give you something that works.