Anyone interested in "package versioning"?

[Stelian Ionescu]

[...]
>>> 2. There's something like a SocialProblem (TM) where Lispers lack
>>>    (a) versioning discipline, (b) dependency versioning discipline
>>>    which exacerbates issues like inadvertent multiple loading, or
>>>    incompatible loading of libraries.
>>
>> Semantic versioning won't help you without automatic tools to
>> determine if the API of a library changed in an incompatible way,
>> e.g. if a function removed a keyword arg, or changed the type of an
>> existing arg.
>>
>
> I would say that semvers should in principle help you detect
> incompatibilities, but as you hinted with "illusion", maybe these in
> practice can't be trusted or relied upon generally.
 
They can't be trusted except for trivial libraries because authors in
practice don't catch all cases where they break the API. The more
expressive the language, the more ways to break the API/ABI. For C/Java,
it's actually pretty easy:
http://abi-laboratory.pro/tracker/timeline/openssl/.
 
 
>>> 3. There's actually no issue in principle: inconsistencies need to
>>>    "just" get fixed by the library vendor/user, or better tooling
>>>    needs to be used to track your project's direct and transitive
>>>    dependencies.
>>>
>>> It's my personal opinion, as is evident in previous messages, that I
>>> think 1 & 2 are issues.
>>
>> You didn't give an example of how exactly those two things are a
>> problem, and how adding those features would solve the problem(s).
>
> #1: Assuming that there isn't incompatible passing of data, if A
> #   depends on B1 and C depends on B2, and in isolation A-B1
> #   works/passes tests, and C-B2 works/passes tests, then A-B1 and C-
> #   B2 loaded together (assuming a non-existent Lisp) should work
> #   fine. The problem being addressed is lack of synchrony in the
> #   universe of Lisp modules.
>
> (My first-order thought is that even incompatible data wouldn't be an
> issue if those data types are properly encapsulated in classes or
> structures, by virtue of the fact that those types become distinct by
> way of different names. I envision that only untyped things could
> cause problems, like [ap]-lists, strings, etc.)
 
It's easy to come up with such a case, where a library:
*) switches from CL epoch timestamps(1900-based) to Unix epoch(1970)
*) switches from Unix namestrings to URIs
*) switches from relative CL pathnames with implicit base to absolute
pathnames. This is properly encapsulated according to your critera
 
In each of these cases, the single versions pass their own internal
(unit) tests, but they do not integrate.
 
  
> #2: If there was diligence is properly versioning libraries, and
> #   diligence in specifying dependency version requirements, then
> #   detection of issues could happen. This is solving recognition of a
> #   possible issue.
 
Regardless of language, you cannot expect diligence in the open-source
world because most libraries are written by people in their free time.
I'd love to be paid to work on open-source libraries, and be able to
take the time to write design docs, have them reviewed, then write code
with unit tests, performance regression tests, etc... Except for a few
cases of high-profile projects(Linux, OpenStack), that's unrealistic.
 
 
--
Stelian Ionescu a.k.a. fe[nl]ix
Quidquid latine dictum sit, altum videtur.
 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/pro/attachments/20160519/11a7cb83/attachment.html>