Wrapper scripts break when other versions of python are loaded first

[Comeani]

Similar to a problem resolved in #11, admin scripts that do not rely on py_wrap.sh break when a python lmod module is loaded first.

This is an example with crc-usage.pl (calls crc_bank.py), but I'd imagine the same issue would occur if we refactor the other wrappers in the same fashion as crc-interactive.py

[nlc60@login0b ~]$ module purge
[nlc60@login0b ~]$ crc-usage.pl sam
|----------------------------------------------------------------------------------|
|      Proposal End Date       |                     04/11/23                      |
|----------------------------------------------------------------------------------|
|                       Cluster: smp, Available SUs: 1000000                       |
|--------------------|------------------------------|------------------------------|
|        User        |           SUs Used           |     Percentage of Total      |
|--------------------|------------------------------|------------------------------|
....

[nlc60@login0b ~]$ module load gcc/8.2.0 python/anaconda3.8-2020.11
[nlc60@login0b ~]$ crc-usage.pl sam
Fatal Python error: initfsencoding: Unable to get the locale encoding
ModuleNotFoundError: No module named 'encodings'

[djperrefort]

Issues with lmod messing up the intended Python interpreter have been popping up on and off again. I would like to find a solution that avoids the problem completely.

One option is packaging the command line apps as a Python package (i.e., adding a setup.py file) and installing them with pipx. This would allow the applications to run in their own dedicated runtime environment. It would also give the developer complete control over that environment - both in terms of the python version and the requirements. The latter point alone is a huge plus for me.

There is some support for multi-tenancy environments in pipx (see this issue). However, I've never tried it myself.

All of this is just me brainstorming. Ultimately we should also see what @iamtroy412 and @buttermutter think.

[djperrefort]

PR #65 should resolve this issue but I want to wait on closing this issue until the changes are deployed.