How DO YOU install a command-line package site-wide? e.g. cowsay

Packaging
1

I have been trying to answer this for myself for many months now and it’s surprisingly hard to figure out. I think what I’m struggling with (and am confused about) will get cleared up if I get an answer to the following question.

Say I’m a sys-admin, and I want to install cowsay site-wide for all 100 users on my system: How do I do it?

[To simplify: Say only on Linux or MacOS.]

Thanks all!
James.

2

[…]

Say I’m a sys-admin, and I want to install cowsay site-wide for
all 100 users on my system: How do I do it?

There are many ways you could go about it. One of the cleanest
options would be something like:

sudo python3 -m venv /usr/local/lib/cowsay
sudo /usr/local/lib/cowsay/bin/pip install cowsay
sudo ln -s /usr/local/lib/cowsay/bin/cowsay /usr/local/bin/cowsay
1 Like
3

I would suggest installing via pipx system-wide.

pipx install cowsay
4 
sudo python3 -m venv /usr/local/lib/cowsay
sudo /usr/local/lib/cowsay/bin/pip install cowsay
sudo ln -s /usr/local/lib/cowsay/bin/cowsay /usr/local/bin/cowsay

Thanks @fungi - is this mimicking what pipx does?

So let me see if I understand this. The first line creates a venv in /usr/local/lib/cowsay. For example, if I su’d to root, I could /usr/local/lib/cowsay/bin/activate, then …

Presumably within this venv, I could update/install various packages?.. So to our point, we install cowsay. So could I do it like I’m suggesting? That is, activate then (while still logged in as root) run pip install cowsay? [Edit: Nope, there’s no activate inside that bin directory.]

Then we simply link to the cowsay command-line script from the global path /usr/local/bin.

Sounds reasonable! I’ll try it.

Is this how sys-admins actually do this kind of thing on multi-user systems?

Thanks tons.
J

5

@FFY00 What if pipx isn’t available to root? I get warnings if I try to use pip as root.(Which I’d need to do to install pipx for root, no?).

As background: I spent days back and forth with some helpful pypa folks when I got into trouble doing the packaging tutorial. It ended up with me uninstalling a bunch of packages I had updated as root, then proceeding with a local venv, only then could I make progress on the tutorial. (PS - on CentOS 7).

Anyway, what you are suggesting doesn’t sound like its viable, unless you can tell me exactly how to do it.

Thanks for your time!

6

Thanks fungi - is this mimicking what pipx does?

Maybe. I’d never heard of pipx until you mentioned it, but then you
get the side task of installing pipx somewhere/somehow too.

So let me see if I understand this. The first line creates a
venv in /usr/local/lib/cowsay. For example, if I su’d to root,
I could /usr/local/lib/cowsay/bin/activate, then …

Presumably within this venv, I could update/install various
packages?.. So to our point, we install cowsay. So could I do it
like I’m suggesting? That is, activate then (while still logged
in as root) run pip install cowsay?

You could, but you don’t have to activate a venv to execute things
from it, everything in there will already know the venv context even
if you invoke them directly from your shell.

Then we simply link to the cowsay command-line script from the
global path /usr/local/bin.

Yes.

Sounds reasonable! I’ll try it.

Is this how sys-admins actually do this kind of thing on
multi-user systems?

I’m a sysadmin, and I sometimes do this, yes. Most of the time,
however, I try to stick to whatever’s supplied by the distribution
I’m running (so for your exact example on my Debian servers, I’d
simply sudo apt install cowsay because getting a different version
from PyPI is unlikely to be particularly important). As part of your
premise, I gathered you specifically wanted to install packages from
PyPI.

1 Like
7

The warnings are in place in order to avoid users from doing it without understanding the consequences, not to say that nobody should do it.
If your distribution (centos, homebrew, etc.) has pipx available, you can use it from there, otherwise you can install it as root as long as you have all other dependencies met.
But perhaps creating the virtual environment manually with venv is a better option in your case. It should be as straightforward as setting up the virtual environment and then symlinking the programs you want available from outside the virtual env to /usr/local.

I know this can be a bit confusing, and I am not going into much detail here, so please let me know if there’s anything you are unsure about (why? how? etc).

1 Like
8

@FFY00 and @fungi - Super helpful both of you. Thanks so much. I’m going to dig in with your suggestions etc. and I’ll be back with a report, or more questions as the case may be. Thanks again!

James.

9

I’m a sysadmin, and that’s essentially what I do, with some tooling around it.

1 Like
10

No matter what you do, always use a virtual environment. You’ll be fine if you do (worst case scenario just nuke the virtual environment and start over).

2 Likes
11

I’ve been using https://fades.readthedocs.io/ for some time, nowadays I use pipx

1 Like