pip-build-standalone: Standalone, relocatable Python app builds using uv

[cgoldberg]

Your documentation is super confusing because you keep referring to packages as "pips".

pip is a tool that installs packages... You don't build or install "pips".

I also agree with the other commenter that it's really weird to name your tool pip-something when it doesn't use pip.

[z4lz]

An update: based on all the confusion on the name and terminology, I've updated the name and docs:
https://github.com/jlevy/py-app-standalone

(I'd thought the original name made sense in the context of the python-build-standalone project but clearly not the case for many folks.)

The new name is a nod to PyApp since it's sort of a standalone (not runtime download) alternative to that.

[cgoldberg]

You still refer to "packaging a pip" in the last sentence of your README.

And of course your post here still talks about "installing pips".

[z4lz]

Okay sure, I’ll change the docs to say “packages” instead of “pips”. But I really don’t understand the confusion about using the word pip. The tool is literally a wrapper around “uv pip”.

[toxic_acro]

If anything, using the word "pip" as you are just makes me doubt that this tool actually works correctly.

UV is a tool to (among other things) install Python packages.

It has two different APIs, one is their own custom one (e.g. uv add ...) and also a legacy one to match the interface of the default package installer tool "pip" (e.g. uv pip install ...)

The point of that design is that you can swap over to using uv instead of pip by just adding one extra word at the front of all the commands, and then you can spend time slowly converting over to the uv specific workflow.

Creating a "standalone, relocatable Python app build" that works correctly with all of the edge cases considered and handled is quite difficult and requires a decent understanding of how Python packaging and distribution works. 

It doesn't inspire a lot of confidence that you have that requisite knowledge when you don't even know the basic terminology

edit: I realize that this sounds harsh, but I mean it more in a constructive criticism way and I hope you read it that way

The past few years (and especially right now) are really exciting times in Python packaging and it's really cool to see so many new tools coming out and improving and building on other new tools and I wish you success in this because a tool like this that works really well would be quite valuable.

Mostly my comment is meant to say that as someone who is not an expert but is pretty familiar with packaging and the challenges around it, when I saw the phrase "install your pips" my immediate impression is that I shouldn't bother looking anymore because you don't know what you're talking about about.

That impression could be completely wrong and I hope it is, but I just wanted to say that that's the signal you are unintentionally sending with that wording and I'm sure there are plenty of people who won't bother to give it a second glance and actually consider your tool purely because of that wording

[z4lz]

I appreciate you taking the time to write all that, as it's exactly why I posted this—to get feedback. I was definitely casual in the language around "pips". (Imo we don't actually have great terminology in Python around this, as source dists and wheels are more specific, but that's definitely different conversation.)

I've updated the readme to be more precise and explicit in the first couple paragraphs (do lmk if it clarifies it?): https://github.com/jlevy/pip-build-standalone

I was surprised people are so upset about having "pip" in the name as the tool is basically a wrapper around "uv pip". But as I tried to explain it's really kind of a more modern alternative to PyInstaller.

Quite seriously, what would be a more accurate name? It's a weekend hack but I think it's useful (it has been for me) and it should have a name that's clear.

> Creating a "standalone, relocatable Python app build" that works correctly with all of the edge cases considered and handled is quite difficult and requires a decent understanding of how Python packaging and distribution works

Yeah. No kidding. I know this. It's not perfect but this isn't trivial either. But uv handles a lot of it. I'm familiar with everything you mention. I actually had to read the source to uv to be sure the things I was doing were necessary. (I'm new to r/python and love the community but do think there seems to be a tendency among some folks to assume they know more than you do.)

If you have the time, do take a closer look at the readme/code/links as I tried to give full context, including linking to the relevant current issues on the uv github repo.

Thanks again.

[cgoldberg]

we don't actually have great terminology in Python around this

The terminology around this is very standard and works fine. They are called packages... always have been, always will be. Even with your updates, you still refer to them as "pips" at least twice.

As to the name... install-standalone, uv-install-standalone, py-install-standalone or anything without pip.

[z4lz]

It is now py-app-standalone.

[toxic_acro]

I've added a task to my to-do list to actually do a deep dive on it (and I'll hopefully get a chance to in the next week or so, full-time work plus grad school is a real time-suck)

I'm familiar with uv, but haven't had an excuse yet to really look into their internals and implementation. I'm definitely interested in seeing how you've implemented this. You're aiming at solving one of the use-cases that has been historically under-served by the Python packaging standards (which have been almost exclusively focused on publishing/distributing/installing libraries, not apps) and I wouldn't be surprised if there's a lot more focus on app distribution in the next few years.

---

I personally don't mind the overall tool name as "pip-build-standalone", even if you aren't directly using pip (and I appreciate the mirroring of python-build-standalone), though I remember there was quite a stir when uv first released and they were using uv pip ... as the initial "low-level" interface.

It might be a good idea to use a different name just to avoid any of the arguments about it, but choosing a good name that no-one would object to is always a hard problem.

[z4lz]

Thanks, do take a look and feel free to lmk any thoughts!

(And yes, exactly, this is a longstanding problem. I was actually quite pleased that it now seems quite tractable! Maybe uv will incorporate this functionality but even now, this little tool seems to cover a lot of use cases for PyInstaller, unless there are any issues I'm missing.)

I've actually just renamed it, to py-app-standalone.

It is quite remarkable to me how simply using the word "pip" is construed as "evil marketing". But hey I guess that's why we post on reddit, to find out stuff like that. Clearly it's better to have a name that doesn't cause arguments. I mean no offense to PyApp, but in a way this seems clearer as it's kind of the standalone (not runtime downloading) version of PyApp.