I have a program that helps manage Python installations: It downloads portable copies as required, resolves and installs dependencies cleanly etc. I’m attempting to publish a snap, but am running into trouble once published/downloaded.
It’s unable to use an already-installed python; for example one that comes with Linux (I’m not sure if it’s unable to locate it on Path, or unable to execute), or initialize a git repo. I’ve used the following plugs: ["home", "removable-media", "network"]. The program partially functions under these plugs; for example, it’s able to download/install/run the portable python builds, and install dependencies.
Do I need to use classic confinement for this, or is there a way arounds? Overall, I need to be able to run a system python (primarily to create a venv, which will be used after), and run git init.
I’m attempting to troubleshoot by addingthe system-files plug, but this evidently also requires a review:
Error: human review required due to 'allow-installation' constraint (bool) declaration-snap-v2_plugs_installation (pyflow, system-files)
Pyflow requires access to whatever directory Python is installed into, whatever directory Git is installed to, and whatever directory a user wishes to create a Python project in. It makes use of the host system to use an installed python to create a virtual environment, git to initialize a repo, and a user’s desired directory to create a file structure.
AIUI, pyflow is meant to drive any python on the system, eg ones in /usr or elsewhere. The system-files is really only meant to be used with /etc since it doesn’t perform any bind mounts from the host into the snaps runtime.
@firefrommoonlight - can you expand on this? Can you describe a couple typical workflows for pyflow and how someone is supposed to use pyflow? Is this meant to aid a developer without root access or meant to configure the system’s pythons?
It allows users to create a Python project, let them specify the version of Py to use and dependencies, and then just makes it work. It prevents users from having to manually create/activate/deactivate virtual environments, provides robust dependency resolution (Python’s Pip doesn’t check for conflicts, or allow for a reproducable environment), and avoids usability and speed problems of existing tools like Pipenv and Poetry. The Github Readme linked at the top of this thread goes into details, and has a terminal GIF showing workflow at its top.
pyflow new (Creates a new project folder IOC python standards. At this point, the Snap will fail to initialize a git repo)
User then modifies the created pyproject.toml as desired to specify a Python version and dependencies, or uses commands like pyflow switch or pyflow install numpy
pyflow install - Checks if a system python is available matching the version specified. If so, uses it. If not, downloads and installs it. It then resolves, installs, and locks dependencies. In the Snap, we can’t find any system Python (Presumably because when it checks for python3 --version etc, the command is blocked), so it goes immediately to downloading a new, standalone one.
pyflow - then runs Python IOC in the correct environment
The user then can change pyproject.toml as desired, run pyflow install, and the changes will occur.
Note: most of the functionality works with the non-classic Snap: The error-handling is fairly robust, so the Snap limitations don’t cause the program to crash, for the most part (Unless the user tries to use it in a non-home folder, and perhaps cases I haven’t encountered yet) but I don’t want to release a limited-functionality version, or release separate Snap-version docs.