PATH warning on pip installation

[arsivci]

But the directory was in my path from the start and when it is there it should work shouldnt it?.

Do you mean all I would have needed is to use the full path in the sudo command for it to work?

Having your present working directory in your path is (was?, I vaguely remember these) considered a security risk. Typically, in order to execute scripts you should run them prepending a ./ if the script is indeed in your pwd. Programs are usually installed to /usr/bin or /usr/local/bin, not somewhere under .local/... In a GUI, you should be asked if you want to execute it even if it was set executable.

[rab0171610]

It is a binary program. It is not just a script. liquidctl is the command to be run. Even if it is not in path, which simply allows user to type the name of the binary instead of the full path to run the program, he was able to successfully execute the command. This was not OPs issue.
Many programs compiled from source in the home directory install to .local/bin/ and it is in my path by default. Even Thunderbird will install there if not installed from repos. Anyway, it is not his PWD. It is in a hidden subdirectory of his home directory and is not a security risk. The program still requires sudo to run and simply allows user to access and manage liquid cooling devices.

[rab0171610]

https://stackoverflow.com/questions/...-of-home-local

According to the Home Directory section of the file-hierarchy(7) man-page, user-specific data should be split among the following sub-directories within $HOME/.local:

• ~/.local/bin for executables that shall appear in the user's $PATH search path. In Python's case this might be a tool like pipenv.
• ~/.local/lib for static, private vendor data that is compatible with all architectures. In Python's case these are libraries like requests.
• ~/.local/share for resources shared between multiple packages. In Python's case this might be the virtualenvs. It is also part of the XDG Base Directory Specification where it is mentioned as the default value of $XDG_DATA_HOME.

From the above observations it should become clear that $HOME/.local has nothing in particular to do with Python itself. pip install --user putting its files into $HOME/.local simply means it is compliant with the recommendations published by freedesktop.org.

If you install packages with sudo pip install, it will distribute the package files according to the Filesystem Hierarchy Standard into the /usr hierarchy instead, which follows the same logic at system-level, just as your distribution's package manager does.

[rab0171610]

So, in other words:

The /usr/local directory mirrors the structure of the /usr directory, but can be used by system administrators to install local or third party packages for all users.

The ~/.local directory now has the same purpose just for a single user.

Usually you'll install your packages with the default package manager using the /usr directory. But since you're using Pip as package manager for your Python modules, these are installed in ~/.local

[rab0171610]

Either way, if the OP had used:

sudo pip install liquidctl

rather than:

pip install liquidctl

the program would likely have installed system-wide instead of locally for one user, i.e. into /usr/bin rather than ~/.localbin/bin.
Also, it could have been installed from the repositories.
The same would apply to programs compiled from source:

sudo make install

vs.

make install

Users without admin privileges can install programs to their home directory but not in the system directories. However, a program such as liquidctl would still need elevated privileges to run, but could still be installed by such user.