Why sudo to install in Linux?

[antdude]

https://sopel.chat/usage/installing/ says: "Latest stable release

On most systems where you can run Python, the best way to install Sopel is to just sudo pip install sopel. (On Windows, leave out the sudo.) Installing with pip will “just handle” dependencies for you, so you won’t need to do so manually (except for installing backports.ssl_match_hostname as described above, if you’re on Python 2.7)."

Why sudo in Linux? What if the user doesn't have sudo access which I am going to do a clean install on my friend's remote Fedora box?

Thank you for reading and hopefully answering soon. :)

[dgw]

So pip install --user sopel instead. Using sudo is "best" because it makes Sopel globally available, which is great in many cases but by no means required.

[antdude]

Thank you for the quick answer, dgw. That should be added in that installing web page. I ran "pip install sopel" without sudo and noticed the installation went into /home/ant/.local/. Does "pip install --user sopel" do the same too? I am hoping it does.

[dgw]

It might. If pip defaults to a user installation because the system install path isn't writable, it prints a warning to the terminal saying so.

[Exirel]

It depends on the user that is actually running pip.

[Exirel]

Why sudo in Linux? What if the user doesn't have sudo access which I am going to do a clean install on my friend's remote Fedora box?

Because Sopel is supposed to be used as a service, and as such can be installed as root and launch as its own user. Using sudo is the most common way to do it, even though since then pip is now able to automatically install into ~/local/—that wasn't the case a few years ago. Things move slowly.

Also, if you don't have root access/not a sudoer on a system, installing a service doesn't sound like something you should do anyway.

[antdude]

Ah, I use the -d parameter when I run sopel to daemonize.

[Exirel]

Yeah, I get that. It's a legacy option, it exists because of how services used to work, what is now called "old-style service": each program was responsible for dealing with its PID and daemonize itself. This is deprecated, especially with init program like systemd.

[antdude]

When does -d option go away for Sopel? V8?

[Exirel]

Not before Sopel 9 at least: I want to deprecate that option in Sopel 8, and provide a plugin that I would call sopel-daemon that would give you a sopeld command line for people who want to keep the sopel -d approach; and then remove it in Sopel 9, with the self management of the PID file.

You have time to adapt!