-
-
Notifications
You must be signed in to change notification settings - Fork 375
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Support the use conda as a base environment for Briefcase apps #596
Comments
Flagging @goanpeca and @tlambert03 on this since they have expressed an interest in this functionality. |
Pinging @jaimergp |
Hi Russel, I might work on this in the coming weeks, so I've been looking into your detailed description (it's excellent! I wish more issues were written with this amount of care) and the questions. I'll try answer them to the best of my knowledge:
|
Hi @jaimergp! I'm here to help in any way I can. That said - if I'm understanding what you've described, (1) sounds like it could be a major blocker. If conda bakes in hard-coded, non-relocatable paths, that's going to be an issue. macOS doesn't require that app files are in a specific location, and it doesn't prohibit apps from being moved. So - I could create an app in Managing this as an "installation instructions" task isn't really viable, either. In order to survive the app signing process, the content of the app needs to be fixed at time of distribution. The only way I can see this working would be for the app to unpack the Conda component into a known system-level folder (e.g., The only way I can see this working is if the path that is baked in is a relative path - i.e., if the "baked" conda paths are defined relative to something app specific (e.g., the location of the executable), then the app remains movable, because the baked paths are interpreted relative to something that can move. However, I can imagine that isn't something conda is set up to do easily. |
Yep, I am afraid your understanding is spot-on. Some stuff like the shebangs in scripts can be reworked to be relative, but some binaries might contain the hardcoded PREFIX. I'll ask around to see if relative paths are even doable; if they are, substantial work will be needed for the conda internals. |
Some relevant links:
But yes, anyway, all those feature requests would involve actively search-replacing prefixes. |
Indeed the nonrelocalability of conda is an issue. I was thinking in the lines
The actual app is the tarballs for all the packages needed, and the first "install". would effectively unpack the app on user space, if the app is moved running the app would either unpack things (first time) or run the actual app. In this case there is the issue of a bash script calling another process which seems mac does not allow for security reasons. |
Ah - that's an interesting idea - each user gets their own conda install, manufactured as part of "first run". I can see how that could work. There's a bit of a bootstrapping problem - if the app is itself Python, how is that python run if the Conda environment doesn't exist yet - but I think it could be possible with some fancy footwork in a custom bootstrap executable. As for macOS security - AIUI, that issue only exists for the primary executable - so if you my "myapp", which immediately starts a different process that becomes the app, that's a problem, because the process that is "the executable" is changing as a result of being run. However, if the core myapp is self contained, but invokes another script contained in the bundle, that should (AFAIK) be OK. |
Ohhh then I think this could work :) |
We can use Micromamba, a static C++ binary that can bootstrap conda environments. |
Ok, on second read I do not follow this, but let's try some diagram here:
If the app is moved it only contains the origin al packages so running it again, would call the napari installed in a predefined location on user space.
How could we get around this @freakboy3742? |
As long as
The ideal situation in your case would be if For context - the issue we had that caused the recent change to briefcase is that "the app" was a shell script that started |
There's some discussion at #1270 (comment) about how this would be configured. Also, as soon as we support this, we should add Briefcase itself to conda-forge and the Anaconda distribution. because packaging environments into apps is a notable gap in the conda ecosystem which we could fill. I'm not sure how many of Toga's platform-specific dependencies have already been packaged for conda, but even if we only supported console apps at first, that would still be useful to a lot of people. |
There is a significant part of the Python ecosystem (especially in the science/data space) that uses Conda to manage their Python environments. Some tools are easier to install via Conda; it therefore follows that some apps may benefit from being based on a Conda environment, rather than the default "vanilla" Python installation.
Briefcase should provide, as an option, the ability to build the app on a Conda base environment, rather than the "vanilla" Python install.
This will involve providing a configuration option in
pyproject.toml
to specify the base/foundation that an app wishes to use (with the current "vanilla Python" behavior being the default); then, depending on the configured foundation, Briefcase should change:Ideally, this would be done via a plugin interface, so that:
Implementation hints
The affected code is all contained in
briefcase/commands/create.py
:support_package_url
propertyapp_template_url
propertyinstall_app_dependencies()
methodIf these three attributes/methods could be abstracted behind an interface, with Briefcase providing a default implementation for that interface that provides the existing behavior, an alternate Conda implementation of that interface could then be installed.
The implementation to be used would be selected early in the lifecycle of the Create command, based upon a configuration option on the app looking up a key in a list of
pkg_resources
plugins (seesetup.cfg
andbriefcase/platforms/__init__.py
for details on how plugins are used at present to define the platforms). Ideally, the plugin interface would allow any command to have overridden entry points (so - Briefcase would define abriefcase.foundation.default.create
plugin, and a Conda plugin for briefcase would definebriefcase.foundation.conda.create
; allowing forbriefcase.foundation.default.build
andbriefcase.foundation.conda.build
et al in future, if required).Questions/Considerations
A (probably incomplete) list of questions/considerations for this project:
.app
folder be moved once an installation has occurred?site-packages
folder in user space, outside the location of the packaged Conda environment.The text was updated successfully, but these errors were encountered: