The problem with OmniOS's 'build your own' view for Perl and Python
A commentator on my entry on Python 2's lifetime mentioned that OmniOS has adopted a principle called KYSTY. To simplify, the core of this principle is that you are not really supposed to use the OmniOS versions of things for your applications. To quote them:
We purposefully ship only what we need to build and run the OS. In many cases, these are not the most recent versions. Except in the most basic circumstance, you should not use these things in your app stack. At best, their versions are stagnant; at worst, they may go away entirely as the OS components they exist for are rewritten or removed.
There are two problems with this when it comes to things like Perl and Python. The first is a variant of the problem with compiling your own version of Python 3; requiring people to build or get their own versions of Perl and Python makes writing small utilities in those more expensive. In practice many people aren't going to do that and will instead use the system versions, with various consequences.
The larger problem is what this does to script portability in
heterogenous environments. Like it or not, there is a de facto Unix
standard about where to find at least Perl and Python and that is at
well known names in
/usr/bin. Making those names not work right in
favour of, say,
/opt/csw/bin/perl means that scripts that work on
OmniOS won't work on other machines and vice versa; each side's scripts
will have a
#! line that points to something that is either wrong or
not there at all. This is not doing people any favours (and yes, some
people still run heterogenous environments with shared scripts).
#!/usr/bin/env hack doesn't help because you can't count on
optional add-on directories being in
$PATH in all cases and all
contexts. In fact I tend to think that it is a great recipe for real
problems but that's another rant.)
The OmniOS approach is arguably sensible for large applications with their own deployment infrastructure and workable if OmniOS is by itself in a homogenous environment. It is not appealing if OmniOS is in a heterogenous environment and what you're writing is glue scripts and utilities and so on.
If OmniOS wants to take KYSTY seriously it needs to not claim the
/usr/bin/python, and so on. OmniOS Perl and
Python scripts should use a private OmniOS name for the OmniOS versions
of those and leave the official public names to sysadmins to set up
however they want (or not set up at all, so that you know that all of
your scripts have to be using your specific version of whatever).