path - environment variable

NB: This post is related to a prior one this month regarding 3rd party package managers.

---

There are two types of environment variables, global (system) level, and local (user) level. Paths are just another environment variable. The tricky part: even though paths are a terminal environment file (see ~.bashrc or ~.profile), applications launched in an X session are presumed to come via the terminal, and so use terminal variables interact with the kernel. Users can also do this directly by exporting variables to the kernel. If we want to see them all

$ printenv

Environment Variables (7:55) Maloco, 2017. Goes over each, notes that they are kept in the

Times when paths are extremely important...

• installing applications without using the package manager
• making some change in an application's libraries because updates killed the link to its dependencies

package manager case (LaTeX)

I get a lot of use out of LaTeX and occasionally add special stylesheets or other packages. Accordingly, I install TexLive (4GB) directly into a home directory folder (typically "latex") and oversee it separately from Arch's package manager. Oversight is with tlmgr. During install, options appear to change the install path to a local directory if wanted. Once completed, the install will give the following message to update PATHs...

Accordingly...

$ nano .bashrc export PATH=/home/foo/latex/texlive/2020/bin/x86_64-linux/:$PATH export INFOPATH=/home/foo/latex/texlive/2020/texmf-dist/doc/info:INFOPATH export MANPATH=/home/foo/latex/texlive/2020/texmf-dist/doc/man:MANPATH

Then one can also add pdf-latex into their completion on Geany or whatever.

package manager case (Python)

Before going further, Colab is the easy Python coding solution through one's browser, and is generously hosted by Google. But we still might have occasion to code Python while offline, on our own system. In 2020, that's probably...

# pacman -S python-pipenv

... still how did we get here? It used to be complicated. Our goal was to cleanly install Python in a user directory, so that it didn't contaminate our distribution if we used pip to add any non-Arch Python modules. We wanted it a solution that:

• allowed interaction with all Arch installed apps
• allowed updating or enhancements using pip, but without contaminating the Arch install.
• allowed libs whether inside our user directory or the larger Arch distro.

This was not an easy prospect, as succinctly described here. The thread overall advises us that we should use our distribution as much as we can and limit pip use to our "user setup" (local directory), and virtual environments. Anaconda is probably the most well known virtual environment/sandbox for Python, but the newer option of Pipenv (# pacman -S python-pipenv)looks even better.

Pipenv (20:48) Corey Schafer, 2018. Schafer now prefers this VE over Anaconda. Arch repository for the pipenv updates, but use pip inside the VE .
Anaconda use (20:48) Corey Schafer, 2017. This fellow uses both Anaconda and pip.