Global or system-wide install

[b00ga]

We have a use case where we want different users to be able to run CORE on the same machine. If they don't run simultaneously, they can both install CORE and run the core-daemon by hand when they want to run an experiment. Not ideal, but doable.

I think I've picked apart the install though to get this to work. Wanted some feedback and discussion around whether this could be a standard option. My install target is Ubuntu 20.04 LTS. I'm testing against 8.2.0 release.

20.04 comes with a package for invoke (only 1.3.0, but seems to work fine) and one for pipx, so for system package install from setup.sh, I instead use:

sudo apt install -y python3-venv python3-pip pipx python3-invoke

There's no Ubuntu package for poetry, so I still use pipx, but create a system-shared directory for pipx, install poetry there, and tell pipx to create "bin" entries in /usr/local.

sudo PIPX_HOME=/usr/share/python-pipx PIPX_BIN_DIR=/usr/local/bin pipx install poetry==1.1.12

If I'm understanding the install correctly, the places where I need to get poetry to install to a different directory are the daemon install tasks.py line 207 and the optional emane python bindings install tasks.py line 417.

According to the poetry docs, we can change the install location with the cache-dir config setting. So first,

(cd daemon && poetry config cache-dir /usr/share/pypoetry --local)

to configure what directory to use. But since the user can't write to that directory (you'll get permission denied), I added a "sudo" to the above referenced two poetry invocations.

Basic testing is working and my users will be putting it through the paces. Does this seem reasonable? Is this perhaps an option we can make available in the installation?

Thanks,
-Shawn

[bharnden]

It is not clear to me exactly what you are looking to achieve. Maybe you are referring to a non-user specific case for a virtualenv install?

There is a package rpm/deb install that will be a part of the next release, which maybe helps you. It would default to installing core into a virtualenv at /opt/core/venv

[b00ga]

Basically I have a few issues with the "user dir install" (where pipx is putting some things in ~/.local and poetry in ~/.config/pypoetry).

• User alice installs CORE on a shared machine with the standard install. The systemd service for core-daemon and it's associated files only live in their directory. So does the sysadmin run the systemd service from alice's home directory? If there are issues, bob can't access alice's home dir to look at the core-daemon installation.
• If alice and bob don't use the systemd service, then they both need to install core to get their local venvs, and deconflict running the daemon when they want to do experiments
• Additional complication, our home directories are mounted from an NFS server, and we use autofs, so the homedirs are only mounted when the user is actually logged in, so if we use the systemd service in alice's home dir, then we she logs out, that homedir goes away.

I suppose we could do the entire install as a shared "coreemu" user or something similar. Alternative to that, as I described originally, I was trying to take pipx's venvs and poetry's venvs and install them in a "shared system directory" (/usr/share/python-pipx and /usr/share/poetry respectively), so the systemd service would run from the core-daemon under the /use/share/poetry install. Then both alice and bob could just run the core-gui, share the same core-daemon, but each run their own core scenarios on the the same shared server.

Hopefully that describes it a little better. But if you have rpm/deb that is using a shared dir on the roadmap, then yes, that may totally solve my use case.

[bharnden]

You can also technically use the local install option -l for a similar effect, albeit, totally different approach. Just throwing that out there.

[b00ga]

Yeah, I saw the local install option, but it's basically just "pip installing" globally to the system python dirs, right? I like the pipx/poetry venv isolation, so was trying to maintain that.

[bharnden]

It may also be worthwhile to make the changes noted to have the automated/dev install case, since I will keep it for that purpose and to not break prior behavior at some level, to install to /opt/core/venv as well to be consistent with the package install virtualenv. I think this would be in line with your desires.