What's the point of #! constructs anyway? According to the POSIX spec:
Applications should note that the standard PATH to the shell cannot be assumed
to be either /bin/sh or /usr/bin/sh, and should be determined by interrogation
of the PATH returned by getconf PATH, ensuring that the returned path name is an
absolute path name and not a shell built in.
It tells us that we should prefer /usr/bin/env sh over /usr/bin/sh, the spec arg
ues that env does not directly point to a path, instead, it looks for the sh bin
ary in your existing PATH variable using getconf. Truth to be told, no one
cares, they both fail at the very basic thing at which they aim for.
That is, expressing an external program as a dependency, one who writes a shell
script and want to share it, better make as little assumptions as possible, this
starts with expressing dependencies.
When we think of dependencies, more than often we think of pkgconf,
autotool, cmake, C libraries and such, leaving out the important fact that there
might be need for x/y external program, however, for some reason, it is never
explicitly expressed. It's as if it would already be magically installed in the
exact version that is needed for the task at hand.
The better anyone could come up with so far is not caring about it, leaving it
up to someone else, probably at at lower level of stack
(hello evil packagers), ultimately condemning the user to face a software
failure sometime even as soon as the building process Yes, you read that
right, a build system that expects its users to have alreadyasse mbled the
pieces of the software they're building. Meson is not the only one wro ng in
this case, Python is too, for it is well-known for its poor dependencies
management, I won't get too deep into that part here but let's say that they
cannot decide on a common way to do things and their package manager,
furthermore pip, is known to introduce breaking changes every single update.
Who did not once try to run a Python script only to have to reverse engineer its
entire dependencies tree just to be able to run the damn thing?
This kind of poor DX does not happen "simply because", it happens because Python
developers are very bad at expressing their scripts dependencies, they more
than often overlook the managing my dependencies versions part of having
dependencies at all. And that's not all! Python packagers also seem to be under
the false pretense that suffixing any Python binary with its major and minor
version is enough.
Somewhere, though, there might be a tiny ray of hope for Python's packaging
ecosystem
So, as you can see lots of wrong from lots of people, that makes for a poor UX/D
X, so what can be done about that?
We need more than just a single unified symbol to express dependencies, we need
the at the very least:
- A very brief and standardized way to express external programs as dependencie
s through a manifest - An (neutral) intermediate program that is able to lookup dependencies through
some sort of universal registry that records user intents on any given system
This way this gives both the final user, maintainers and developers more freedom
while keeping us sane.
When external programs are required at any steps of that building process then i
t should be able to be lookup the information whether a given program is availab
le, what exactly it is and how it can use it. In contrast to the current state o
f things where a path, symbolically, means a dependency, the program would look
at the user intents from previously installed packages and test their hashes, th
at is, the clearest form to express a dependency. The hash would be made ouf of
their name, their exact and precise version. A clear distinction should be made
between programs that the user himself compiled and installed programs, unless a
gain, it expressed its intent to compile a precise version as-is without chainin
g its behavior. It's all about what the user want.
Needless to say that it is not as simple as providing an API that calls itself
find_program huge shout-out to the dumbest of all: [meson] which by the way
looks like another attempt at world wide domination through softwares enslaving
its users.
That's it I will no longer be fooled by semver, paths and /usr/bin/env, suffixes
or anything of the sort.