Wandering Thoughts archives

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).

(The #!/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 names /usr/bin/perl, /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).