Hacker News new | ask | show | jobs
by the_mitsuhiko 660 days ago
> 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.

1 comments

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!

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.