Next steps

[Stelian Ionescu]

> On 17 Nov 2021, at 10:35, Stelian Ionescu wrote:
> 
>>> 
>>> 
>>> Mostly sounds good to me. Assuming you're still interested in more
>>> expressive version numbers and constraints for 3.4, I'll work on moving
>>> that off the back burner.
>>> 
>>> 
>> 
>> 
>> Adding fine-grained version constraints would be a big mistake. Where they've already been implemented (Ruby, Python, Haskell), they've invariably lead to authors selecting overly restrictive contraints because there's no automatic way to determing the minimum version required from dependencies.
>> In turn, that makes even installing a package a nightmare because it often leads to unsatisfiable dependencies and having to (manually) backtrack until one can find a combination of compatible packages. The distribution model that Quicklisp has, by snapshotting the "world" once a month and ensuring that they all compile is much better so let's keep it that way.
>> 
>> 
>> If you think I'm exagerating, ask people that are familiar with the process of having to update a Ruby webapp (or a Jekyll blog with many plugins), or even a Python virtualenv-based server. Especially the Ruby community went down this rabbit hole to far that it's no wonder they were the first to adopt Docker back in the days: instead of subjecting users to the dance of "let's see if I can even get this to install" they ended up shipping a whole container as a workaround.
>> 
> I have mixed feelings about this:
> 
>  1. I agree that the situation in Python is a hot mess. I'm not sure how much this is due to versioning messes as opposed to the excess specificity that one gets from `pip freeze`, and another confound is the multi-headed horror that is Python package construction and management.

Dependency freezing is yet another symptom of the problem: because the dependency hell makes it difficult to find a mutually compatible version set, authors make their own life easy by freezing deps, but that works poorly with the rest of the ecosystem.
The last time the problem of incompatible versions bit me I was trying to update my blog based on Octopress+Jekyll, and found that the latest release of each of the packages that I required - including plugins - couldn't be installed together. I had to manually backtrack by tweaking the versions (since rubygems didn't do that automatically), and it took me a few hours to converge on a working install. The year after I switched to Hugo.

>  2. I *desperately* want to add version upper bounds. There is a real problem of having someone change a library under one's system, and *pace* Faré, sometimes one does not have the resources to handle updates to every library in one's build chain.

It's part of the social contract of open source that you get things for free but you need to stay up-to-date with your dependencies.
If a library changes too often, it's a social problem and shouldn't be addressed with technical means: talk to the author and ask to keep backwards-compatibility for a while longer or remove/replace the dependency.
I cannot stress enough how much better the Quicklisp monthly distribution model is compared to what I see anywhere else. Once you open this Pandora's box there will be no going back (are you open to removing the feature from ASDF if it goes bad ?).

> It's always better for the poor user to see an error message saying that something won't work because of a library update, instead of seeing some kind of horrible mess with no clue where to look.
> 
>  3. I am not that worried that we will end up in the kind of mess that concerns you: right now there are an enormous number of Lisp libraries that don't even have version metadata *at all* . So if people want to use expressive versioning in a sub-region of the lisp development ecosystem, that is unlikely to cause the problems you see, and might help *some* of us manage our dependencies.

I am worried because once you make something easy, people will be tempted to use that feature. Authors aren't currently adding metadata because it's purely decorative and there's no real gain in maintaining that.

--
Stelian Ionescu