Activating Conda Environment #32
Comments
|
Right now the primary use case for the conda plugin is to ship Python software in an AppImage. It looks like you're trying to do the same. In that case, activating the environment is usually not necessary, as you can simply call the "right" Python, the path can be predicted (in your case Being able to activate the environment requires solving the two issues you mentioned in some good way (well, it all boils down to #12). If you have a solution for that, please post it. I haven't come up with a good one yet, unfortunately. Everything proposed so far is pretty much a hack. |
|
I also thought that the "right" environment will be called from the get-go, but that wasn't the case. Unfortunately I also don't have a solution for this. I tried to modify the shebang when creating the AppImage and while starting the AppImage: both were very dirty hacks and didn't work. |
This removes some of the wrong paths pointing to the build location of the AppImage by using a different shebang and some environment variables. Fixes linuxdeploy#12, linuxdeploy#25 and linuxdeploy#32
This removes some of the wrong paths pointing to the build location of the AppImage by using a different shebang and some environment variables. Fixes linuxdeploy#12, linuxdeploy#25 and linuxdeploy#32
This removes some of the wrong paths pointing to the build location of the AppImage by using a different shebang and some environment variables. Fixes linuxdeploy#12, linuxdeploy#25 and linuxdeploy#32
This removes some of the wrong paths pointing to the build location of the AppImage by using a different shebang and some environment variables. Fixes linuxdeploy#12, linuxdeploy#25 and linuxdeploy#32
This removes some of the wrong paths pointing to the build location of the AppImage by using a different shebang and some environment variables. Fixes linuxdeploy#12, linuxdeploy#25 and linuxdeploy#32
This removes some of the wrong paths pointing to the build location of the AppImage by using a different shebang and some environment variables. Fixes linuxdeploy#12, linuxdeploy#25 and linuxdeploy#32
This removes some of the wrong, absolute paths pointing to the build location of the AppImage by using a different shebang and some environment variables, set by the linuxdeploy-plugin-conda-hook at the AppImage start. Fixes linuxdeploy#12, fixes linuxdeploy#25 and fixes linuxdeploy#32
This removes some of the wrong, absolute paths pointing to the build location of the AppImage by using a different shebang and some environment variables, set by the linuxdeploy-plugin-conda-hook at the AppImage start. Fixes linuxdeploy#12, fixes linuxdeploy#25 and fixes linuxdeploy#32
This removes some of the wrong, absolute paths pointing to the build location of the AppImage by using a different shebang and some environment variables, set by the linuxdeploy-plugin-conda-hook at the AppImage start. Fixes linuxdeploy#12, fixes linuxdeploy#25 and fixes linuxdeploy#32
This one is similar to #25 and #12 but slightly different, I use the plugin to pack local files into a AppImage with Conda runtime:
AppDir/./linuxdeploy-x86_64.AppImageHere is the script for creating the AppImage and here the start script. It is kind of hacky.
It actually works, but only as long as I don't delete
AppDir/(line 44). It uses the "build" environment for execution, as soon as it is gone, the application doesn't work.I guess the problem is, that Conda uses a lot of hard-coded, absolute paths. Is there a way around this? Meaning being able to activate the Conda environment when launching the AppImage?
The text was updated successfully, but these errors were encountered: