asdf version dependency

[Faré]

On Wed, Mar 16, 2016 at 7:52 PM, Alexandre Rademaker
<arademaker at gmail.com> wrote:
>
> https://common-lisp.net/project/asdf/asdf.html#Version-specifiers
>
> So I can say that my system depends on a (:version :OTHER "x.y.z") which
> means a version >= x.y.z. Can I say explicit enforce a dependency of a
> particular version ? That is version equal of x.y.z instead of
> greater-than-or-equal x.y.z?
>
No you can't, and I actually object to such a counter-productive
feature EVER being made part of ASDF. It very much goes against the
principle of ASDF configuration:

"THOU SHALT ALLOW EACH ONE TO CONTRIBUTE WHAT ONE KNOWS WHEN ONE KNOWS
IT, AND THOU SHALT NOT EITHER REQUIRE OR ALLOW ANYONE TO CONTRIBUTE
WHAT ONE DOESN'T ACTUALLY KNOW."

Declaring incompatibility with old versions you know is good. You've
seen those versions, you know why trying to use them will cause
headaches to whoever tries to use them (and to you when they come
whining about it). So you forbid them. Users must use a newer version
with fixes to known issues. Fewer headaches.

Declaring incompatibility with future versions you can't possibly have
seen is a lie, and it's evil. Not only you can't know that they will
be incompatible, but anyone who isn't an utter idiot knows that sooner
or later there will be a bug found in that dependency, an essential
feature lacking, or worse, a major security issue, that will cause its
version to be bumped past what you arbitrarily declared to be the
maximum compatible value. People will HAVE TO upgrade, and your
declaration only makes it harder, for now they will have to patch out
your declaration. If other idiots followed your lead, maybe hundreds
of libraries will have to be recursively patched to account for the
version change in some dependency at the bottom of the dependency
graph. Major idiotic move.

BIG DESIGN PRINCIPLE:
There are three distinct roles with respect to a software system.
1- AUTHOR: Writing the system.
2- USER: Using the system in another system.
3- INTEGRATOR: Assembling a bunch of systems into an overall
application/set of applications/deliverable/machine image/etc.

It is the INTEGRATOR, in role 3, whose job it is to build software
together, make sure that all libraries are mutually compatible, pass
all tests, are actually usable, etc. He and only he should have the
last say as to which exact version is used for each and every library.
And if he isn't completely incompetent, he keeps all those libraries
under some kind of version control. An example competent integrator is
Xach and his quicklisp.

When you're specifying dependencies in a .asd file, you're a USER in
role 2 with respect to that dependency. Anything you do to prevent
future upgrade is a stupid counter-productive move that only gets in
the way of the future INTEGRATOR.

A .asd file is a tool for role 1 and role 2, and NOT for role 3. If
some weird integrator wants to use an asd file to track versions,
rather than git, he's wrong, because for most libraries asd version
strings do not completely identify the exact code being used. Even
assuming asdf version strings were enough, and/or were a useful
checksum, this still shouldn't be a feature of a regular ASDF system.
If this software integrator wants to specify exact and/or future
versions in a defsystem, he first will have to define a subclass of
SYSTEM that will allow those specifications.

—♯ƒ • François-René ÐVB Rideau •Reflection&Cybernethics• http://fare.tunes.org
Obama's economic policies will be so remembered that he'll be the president
picked for the face on the hundred trillion dollar bill.