1. yum vs pip - evidently I should use yum unless it doesn't work, then
I use pip
Yes, and you should use
yum list
to find out what is installed and available via yum. Also note that
ACS serves as a front-end for yum, so usually they are
interchangeable. I don't use ACS, so I can't be more specific than
that.
The reason you should try yum (or ACS) first is that yum handles
packages that IBM (or someone else, if you configure your system to
look elsewhere) has specifically compiled for PASE. As Mark said,
these are not limited to Python-related packages.
But in the context of Python, you should understand that a common
implementation strategy for Python packages where performance is
particularly important is to write the performance-critical code in C
or other compiled language (because Python is comparatively slow),
then use hooks and wrappers to interface that code with Python.
Perhaps the best and most important example of such a package is
NumPy, which is meant for working with large amounts of numerical
data.
Plenty of other Python packages are implemented solely in Python, with
no "compiled" parts to speak of. (Technically, Python source code
"compiles" into byte code, and then the Python VM runs that byte code.
But for various reasons, it's simpler to just consider Python an
interpreted language.) If a package is pure Python, and all its
dependencies are pure Python, then "installing" it is essentially a
matter of finding all the source and copying it to a suitable place on
the target machine.
Now, on a mainstream system, if you're focused on working with Python,
you typically don't need to know about yum at all. You just need pip.
If your machine is equipped with a mainstream C compiler, pip will go
ahead and use it to compile any C-implemented portions of impure
Python packages. On a full-blooded Unix or Linux system, this works
great. Even on Windows, the picture is looking better and better. But
most folks who write these packages do not know the intricacies of
PASE, so even though your PASE may have a C compiler, the compilation
doesn't always work when done via pip. But it sometimes does. (I
surprised Kevin one day when I told him pip successfully built bcrypt,
I think it was, on PASE.)
Naturally, any pure-Python package will install fine on PASE using pip.
2. /QOpenSys/pkgs/bin vs QOpenSys/QIBM - The first is open source, the
second is not, and I should only use the first
The first is what is used by yum. Anything new will be there.
The second was used by the licensed program 5733-OPS, which was an
earlier attempt at providing "open source" to PASE. I think the
reasoning behind having a licensed program was "IBM i users are
familiar with licensed programs, so let's give them that". But it
turns out this delivery system is a comparatively heavyweight pain in
the butt, both harder for users to install and harder for IBMers (like
Kevin Adler) to produce. Anyone coming from the other direction
(already familiar with open source on other platforms, but trying to
see what they can do with it on the i) found 5733-OPS stunningly
obtuse and byzantine. Especially if they are used to using yum or pip
or npm or whatever.
Since switching to yum, IBM has been able to crank out dozens of new
packages for PASE in the time it used to take them to add one option
to 5733-OPS. (And there was a limit to the number of options, too. I
think 15. I don't know how they would have handled a 16th release.)
So yeah, just 5733-OPS is, from today's perspective, just bad news all
around. I'm sure it was better to have Node.js available via 5733-OPS
than to not have Node.js available at all, but now that we have yum,
there really is no looking back.
3. python venv - I can make one, but I don't need it for MKDocs
Virtual environments are not strictly needed for anything. You can get
pretty far in your Python journey without ever knowing or using one.
To be honest, I don't use them much myself and haven't yet really
integrated them into my workflow.
The main point of them is to be able to keep various Python
environments somewhat isolated from each other, mainly to manage
dependencies. Each venv can have a different Python interpreter and a
different set of installed packages. This is especially useful when a
package breaks backward compatibility and you have some software that
depends on the older version and some that depends on the newer
version. You can have two different venvs, each with a different
version of that package in question.
John Y.
midrange.com
