#pyapp

1 messages · Page 1 of 1 (latest)

runic kelp
#

I like pyapp a lot more than the alternatives (e.g .pyinstaller which in single-file model is agonisingly slow to launch and w/ multi-file you run into execution/quarantine issues on Mac) - there's just a couple of things that maybe could be done better?

If I were to package my app with pyapp, I'd need to think about data persistence - my app's size on disk ballooning with every new release my users download/install. What can we do to mitigate this? I see that pyapp uses https://docs.rs/directories/latest/directories/struct.ProjectDirs.html#method.data_local_dir but $TMPDIR might be more appropriate? Should a new release be able to prune old releases? I also worry about the terminology - pyapp says that it's "installing" my app but it's really just unpacking it (+ fetching dependencies if skip_install is not set, but Windows users in particular might imagine something else entirely). Users might feel a little uneasy about a self-installing CLI - "unpack" is more palatable. I might want to let users decide what the unpack location should be, e.g. if pyapp could be told to respect the value of MYAPPNAME_UNPACK_LOCATION env var falling back on the default dir if it's unset.

The other thing I'd like is maybe to simplify the bundling of app deps. I see there's now the option to bundle an sdist/wheel of my app in addition to the Python dist, but pyapp will still need to grab all of my Python dependencies from PyPI. Would it be possible, say, for pyapp to unpack the Python dist AOT, install the provided wheel and all of its dependencies in it and repack it? I'm doing this manually right now (having to remap python-build-standalone releases to Rust build targets),but it'd be really helpful if it could be managed by pyapp.

velvet badger
#
  1. I won't use a temporary directory but I am planning on adding a command to purge other releases. Also, size I think wouldn't be too much of an issue because if they do the self update method it utilizes the same installation directory so they would only be actually creating a new installation when they download a new executable
  2. That's interesting, I suppose I'm comfortable with changing installing to say unpacking if --only-binary :all: is found in https://github.com/ofek/pyapp#extra-arguments
  3. Sure, I'm okay with choosing the installation directory with an environment variable
  4. I'm hesitant to do any embedding of dependencies (I could be convinced otherwise) but I am planning on adding a third way to install projects which would be a path to a requirements file
#

update about 4 there, actually embedding of dependencies I will never do because of cross compilation complexity

#

I see there's now the option to bundle an sdist/wheel of my app in addition to the Python dist
just FYI the main purpose of that is so development versions can be distributed

velvet badger
devout tapir
velvet badger
#

writing flowcharts in Mermaid took longer than I thought

velvet badger
#

Docs deployed

#

side note: the version I'm releasing tonight changes the default isolation mechanism to virtual environments for space saving reasons and it makes me super sad that the standard library venv is horrendously slow

#

most of the time is spent calling ensurepip

velvet badger
devout tapir
#

Thanks! I have a blog post planned in response to https://changelog.com/podcast/526#transcript-323 and I'm hoping to try PyApp against the tools mentioned in the episode as a demo of new options for Python-based tools to use for single-file binaries

devout tapir
#

Is pyapp considered announced yet, so mentioning it in a blog post is okay?

velvet badger
devout tapir
velvet badger
#

nice! a few thoughts:

  1. That is true that the better user experience comes at the cost of the developer's time but that is just what I feel is necessary for Python
  2. My plan is to update the formula for Hatch on Homebrew to use the binary actually that way upgrades can happen with just the tool without having to wait for the package manager to have an update (I want to do this for winget and other ecosystems as well)
#

also the distributions that we use by default I'm pretty sure are optimized more than whatever the package managers would provide as a base Python

runic kelp
#

personally, if I install something with a pacman, I want the pacman to remain responsible for updates. Auto-updating desktop apps going out of sync with their brew versions is a wart, a limitation of the system, not something that should be done intentionally

late crown
#

Yeah, I'd second that. Either let the packaging software manage the versioning or don't use it.

velvet badger
#

you can do that sure but I would like to give users the option

#

the self management behavior can be disabled at build time also

molten plover
#

oh, you updated PYAPP_SELF_COMMAND to support for disabling with none now. Well, kinda, I see you just generate random command name lmao

velvet badger
#

😅 yeah it was just easier than changing the structure of the code for commands

#

if a user guesses right then they deserve that functionality

velvet badger
velvet badger
velvet badger
velvet badger
runic kelp
#

nice, thanks!

velvet badger
#

fixed PyPy 2.7 (this is supported just because it's easy) and also added a GIF file to the readme and docs home page https://github.com/ofek/pyapp

north moon
#

Couple of thoughts:

  • I generally like and use pipx too and support Brett's blog, but I usually prefer brew if the tool is there. My daily s/w upgrade ritual rivals my daily tai chi and bass practice in terms of time spent and steps involved 😄 - the fewer tools the better (and pipx does have the occasional problem that they break when brew upgrades the python executable)
  • pyapp is very cool, congrats on its release. I've pointed my $work team at it as something to investigate for a CLI we are releasing soon. FWIW, that tool is replacing one that did a bespoke self-upgrade that generally our users strongly disliked. They wanted total control over tool upgrade boundaries, which makes sense given their use cases (and the fact that breaking changes can happen beyond our control).
velvet badger
true goblet
#

Congrats on the release!

#

Specifically if I just guess at hatch build app I get an app/ folder but it just contains a whl

#

hatch build -h doesn't mention builder plugins, which is the next thing I just looked for

#

(mentioning the stream of thoughts ^^ just in case it's helpful for dumb new user UX info!)

#

Aha! It's hatch build -t app

#

(Again spewing thoughts in case they're helpful -- it'd have helped to find that faster if the language in --help matched the language on https://hatch.pypa.io/latest/plugins/builder/app/ e.g.:

The builder plugin name is app, usable as a `target` via hatch build -t app.

(Happy to send a PR for ^^ if any is useful soon as I try out PyApp which looks very exciting!)

#

The outputted thing fails because it's I guess looking on PyPI to download the project, but using the hatch.version.vcs's version, which won't exist on PyPI, so that's next on figuring out how to configure

#

Hrm, PYAPP_PROJECT_VERSION=v2023.12.11 hatch build -t app doesn't appear to be the answer, ok gonna take a break for a bit, I assume I'm close.

velvet badger
#

yeah I'm very sorry about the Hatch docs. my original strategy about that was to document absolutely everything but not necessarily in a coherent way and I plan to fix that soon

#

to be totally transparent I probably would have lost motivation in the beginning if I tried to also make perfect docs, so I think I made the right choice at the time

true goblet
#

1000%

#

No need to apologize at all!

#

20 minutes to get close is way above average on docs I have to deal with 😄

#

(especially so having just seen the message in #hatch)

#

I'm quite in sync with Paul it seems on questions :D, he also asked some other one that I had (about where the heck these virtualenvs were ending up) and one further one in that thread

#

In case it also bears repeating -- you are doing great work. This and hatch seem like really big deals in places where there was prior stagnation. Feels somewhat @mighty parcel-esque (to hopefully give both of you deserved compliments at once :D)

velvet badger
velvet badger
true goblet
#

So here's a silly question -- pyapps are platform specific? I guess clearly the answer is yes, both because I see the one I build doesn't work on macOS and I guess because in retrospect I do know that the platforms obviously have different executable formats

#

What's the recommended way to build them then, one per platform? Do I need any more specific than that or just one per platform?

#

(E.g. musl vs glibc or whatever else I'd need to worry about)

true goblet
#

Hrm, quite involved.

velvet badger
velvet badger
tacit stump
#

Awesome!

velvet badger
velvet badger
#

notably, split the previous single one in two

runic kelp
#

Does PYAPP_FULL_ISOLATION just mean that dependencies will be installed in the “system” site packages?

late crown
#

@velvet badger does pyapp allow for a configuration to be read from pyproject.toml/setup.[py,cfg]? It would be nice to have that to skip extra steps with env vars

#

also, does it work well with entrypoint-based plugins? is it possible for user to install extra dependency to the app env?

velvet badger
velvet badger
late crown
velvet badger
#

you can use it without Hatch fully, perhaps explain exactly what you mean by reading from those files?

late crown
#

lets say I am writing a cli app, I want to ship it with pyapp, could it read name, version and dependencies from pyproject.toml instead of me manually setting the env vars?

velvet badger
#

No there is no option to pass it a config file

late crown
#

well, it would be neat to have

velvet badger
#

the dependencies wouldn't do anything, those are installed at runtime from PyPI or you pre-build a distribution with everything

#

I will add build time resolution with UV but haven't had time

late crown
#

well, name and version would still be nice to have

#

I am tempted to try and package Poetry with pyapp and see how it will go

velvet badger
#

definitely better than an install script

late crown
#

yeah, we default to pipx now 😄

velvet badger
#

binary avoids having to get Python in the bootstrapping phase

late crown
#

the most pain comes from people using pip and installing poetry in their projects

#

merging pip and pipx would be neat

runic kelp
true goblet
#

Is PyApp working for others? I get failed to select a version for the requirement zip = "^1.2.3" locally and in CI when running hatch build -t binary as of the past day I think

velvet badger
sick shuttle
sick pawn
#

Given that pip works at per-Python-environment level, while pipx works one layer higher, I don't think that's feasible unless we broaden pip's scope.

quasi chasm
#

Hello everyone!

Do you know if I can embed a wheel, and install the dependencies of the wheel with a dependency file ?

image.png
quasi chasm
#

Second question, can we embed juste a single python file and not a whole python package ?

quasi chasm
#

Will work on a contribution tomorrow, we want to use an artifactory mirror for every pyapp needed resources 🙂

I will just add two environnement variables in order to let the user change the repository of the of python standalone builds and uv 👍

#

People will be able to target their fork in their own SCM for example or use their artifactory

#

@velvet badger

quasi chasm
velvet badger
#

thanks for the ping, I didn't get notifications for this channel

quasi chasm
#

Let me know if you need anything!

velvet badger
velvet badger
velvet badger
sudden oar
#

@velvet badger hope you are doing well. I noticed that the hatch pyapp builds for OSX appear to be signed properly. It looks like you have quite a complex build process to get this done. Is this the only way to accomplish this right now?

velvet badger
#

if you're shipping just a binary then you need only one Apple certificate, if you also desire a PKG then you need another as well

sudden oar
#

thanks, as always, for the quick response

loud silo
#

hi, been having this issue opened since July 2024 😄

#

been trying to figure it out a few months ago but failed and gave up

#

maybe I missed some flag

velvet badger
loud silo
#

Ty

velvet badger
loud silo
#

hi, any news on my issue 😅

velvet badger
#

ah, you should turn your directory into a package and then you can embed that

loud silo
#

that sounds like something I've never done before

#

let me see

velvet badger
mighty aspen
#

I know PyApp's main use case is to package a Python app in to a single executable, but can it also be used to embed Python in a Rust app?

royal knot
#

I think you need PyO3 for that

mighty aspen
#

Hi @royal knot, yup, PyO3 definitely for the interface between the Rust and Python, but I don't think it helps with embedding a Python interpreter. PyOxidizer had some capabilities around this, but the project is quite dead at the moment, so I was wondering if PyApp could help for this use case.

royal knot
velvet badger
mighty aspen
#

Hey @velvet badger, that's a good clarification, makes sense. Does PyApp currently help with compiling a binary that includes a rust app with the Python?

velvet badger
mighty aspen
#

Ok, sounds good - totally understand if it isn't the focus of the project. Ya, I had reviewed the diagram, but I think it is a Python focused decision tree. If there was rust code it wouldn't need to bootstrap itself.