Next steps

[Robert Goldman]

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.

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 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.

Cheers,
R
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/asdf-devel/attachments/20211117/dd1e3957/attachment.html>