[HN Gopher] Qlot: Common Lisp Library Manager
___________________________________________________________________
Qlot: Common Lisp Library Manager
Author : ducktective
Score : 38 points
Date : 2024-08-06 05:04 UTC (3 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| koito17 wrote:
| Seems like an attempt to bring "lockfiles" or related concepts to
| Quicklisp. This is a desperately needed quality-of-life
| improvement for "modern" Common Lisp development.
|
| However, I wish people in the Common Lisp community weren't weary
| of using ASDF directly. It already supports versioning and many
| features that do not exist in Quicklisp -- despite the fact
| Quicklisp wraps ASDF -- such as a package that depends on a
| version of a library newer (or older) than what exists in the
| current dist.
|
| It's kind of impressive that Common Lisp is the only language I
| use where I can't expect code written today to work next month
| due to Quicklisp lacking versioning outside of the date attached
| to dists.
| g11479 wrote:
| fare the guy who briefly took over asdf development before
| quitting common lisp entirely to do scheme, or whatever he's
| doing right now, spent significant amount of time turning asdf
| from a 10kb file into 3000kb file in order to solve problems
| that only he himself cared about, or possibly only google cared
| about because fare worked for google at the time (building
| portability library that ignored and force-superseded existing
| solutions, and trying to eliminate corners cases of SAT
| solving). there was a period where he was harrassing (this is a
| subjective interpretation of the events, but this is my side)
| implementors to incorporate his recent asdf changes, that were
| breaking left and right to the point that multiple common lisp
| maintainers of multiple common lisps were considering pulling
| asdf from their repos entirely. things have stabilized, because
| fare quit and there's no longer volatility. we're at a point
| where there's just no concensus about relying on asdf for
| anything, and while some people go all in on 30% of available
| functionality (as opposed to customary 5%), equally many
| people, the majority, use it as a glorified (load)(load)(load).
| this is an unfortunate side effect of activist developers in
| small communities: they can have outsized long term effect on
| how things are done.
| kazinator wrote:
| In the Meta-CVS project, I carried a copy of asdf.lisp in
| which the package was renamed to zxcv, to isolate from the
| ASDF churn and be able to run my version of ASDF possibly
| with my fixes even in a Lisp that has ASDF preloaded.
|
| ASDF is the only build system I know which broke on me when I
| tried to fool it with a link farm (lndir command) into
| building in a separate directory. It resolved the paths using
| the _truename_ function which eliminates symbolic links, and
| then calculated the .fas file names from the canonicalized
| paths, thereby depositing compiled files into the original
| directory rather than in the symbolically linked tree.
|
| ASDF also depends on symlinks for external organization. .asf
| files are often symlinks to the real location, and without
| these symlinks, things don't work.
| g11479 wrote:
| i have a patched version of asdf 1.369 which was maintained
| by gary king, with contributions from luminaries like
| nikodemus, chrodes, weitz, pvaneynd and kevin rosenburg.
| i've patched it to support the recent extensions that
| people seem to like (extra parameters to defsystem, like
| author). you can drop it into your implementation and
| quicklisp and it just works. asdf 2, asdf 3 happened since,
| they solve some kind of problems, i guess whatever google
| needed to do with its fleet, or maybe it's "easier to
| maintain", but it's not the kind of problems that surface
| in like 60% of quicklisp packages.
| redwoolf wrote:
| My thoughts as soon as I read the README: what's wrong with
| asdf?
| mike_ivanov wrote:
| UX
| blast wrote:
| ASDF is by far the hardest part of the CL ecosystem to work
| with. I find it unusably complicated. It's the autotools of
| CL.
|
| Thank god for quicklisp.
| aidenn0 wrote:
| That's interesting because I find it to be one of the most
| ergonomic build tools I've ever worked with. It sits
| somewhere between make and autotools in terms of what it
| does and I find it far easier to use than either.
| g11479 wrote:
| it's fukamachi-ware, guy has a bunch of own solutions in the
| web development space, i suspect driven by his specific
| needs. they are, fwiw, not as idiosyncratic as some of the
| artisanal common lisp one-man solutions can be, but they are
| distinctly and recognizably their own thing
| aidenn0 wrote:
| The only time I've had CL code break due to lack of versioning
| was when I was depending on stuff written by the author of
| Qlot, so I either avoid or locally pin stuff written by him.
|
| Most of my dependencies are really quite stable.
|
| [edit]
|
| I thought of a place where things broke that aren't related to
| Fukamachi; sometimes foreign libraries have changed to the
| point where they won't grovel any more, but I don't think
| that's something that Qlot aims to solve.
| mike_ivanov wrote:
| I bet my money on https://github.com/ocicl/ocicl
|
| Edit: as much as love fukamachi - but still
| dang wrote:
| Related:
|
| _Ocicl - An ASDF system distribution and management tool for
| Common Lisp_ - https://news.ycombinator.com/item?id=35973000 -
| May 2023 (32 comments)
| gibsonf1 wrote:
| This is great news. The updates to SBCL broke some libraries
| (that is, sbcl got more thorough in finding bugs that some
| libraries had) and I've had to load patches in for them because
| of the quicklisp limitation in a patch file. This will make life
| much simpler as do all of Fukamachi's libraries in general. (His
| internet suite is fantastic)
| behnamoh wrote:
| Those who still use Common Lisp or some variant of Lisp (other
| than Clojure), what's your reasoning behind choosing this
| language over the more mainstream options? I understand that Lisp
| has some powerful features, but almost everyone that I've talked
| to holds reservations for those.
|
| For example, Lisp macros are amazing. BUT... this is not good for
| communicating code in big teams.
|
| Or live (image) programs are an interesting concept, but git
| versioning them is much more difficult than traditional source
| code versioning.
|
| Or hot code reloading, which sounds like a powerful concept
| except that companies would rather log and document their
| codebase. It also makes it challenging to keep track of the
| state.
|
| If you force teams not to use macros, then a great reason behind
| s-exps goes away. And in general, if you take these features away
| from Lisp, I'm just not sure what use case Lisp can serve.
___________________________________________________________________
(page generated 2024-08-09 23:00 UTC)