asdf version dependency

Attila Lendvai attila at lendvai.name
Fri Mar 18 09:53:08 UTC 2016


for some 0.02, this is my high-level perspective:

the name of an entity/concept is some letters/sounds/notation that we
humans use to point to it while communicating with each other.
sometimes we use computers to achieve that, e.g. when packaging a
library together with a .asd file.

from this perspective, the question is: should names in the ASDF model
be a simple string of characters, or should they be represented as a
more formal encoding that includes the state of the entity being
pointed to (i.e. the version information).

IOW, for me the question boils down to this: shall ASDF implement
version control features?

and looking at the unfortunate fact that source code is still saved
into flat text files today, and at the complexity/requiremenets of git
& friends to deal with the state of these text files, my gut reaction
is no, it should stay far away.

professional integrators should use professional VCS systems to mark
specific states of the entities they are integrating. i think anything
less is just wasted efforts that grows complexity without solving the
issue beyond the trivial cases. e.g. what about quicklisp, or
integrators in general? shall they bundle different versions of the
same system (they can't, because the lisp package namespace is
shared)? or will they just resort to whichever tools they are using to
resolve the integrator's headaches and just entirely ignore the new
ASDF feature?

FTR, for our libs i use darcs and overlapping tags to keep track of
the collective state of the dependencies when packaging various
different apps that use various different subsets of these
dependencies. for foreign libs i also use whichever VCS is used to
publish them.

-- 
• attila lendvai
• PGP: 963F 5D5F 45C7 DFCD 0A39
--
“Selfishness is not living as one wishes to live, it is asking others
to live as one wishes to live.”
	— Oscar Wilde (1854–1900), 'The Soul of Man Under Socialism' (1895)



More information about the asdf-devel mailing list