Ocicl – An ASDF system distribution and management tool for Common Lisp
github.com
github.com
Quicklisp is pretty bad but at least it's -somewhat- comprehensible and Lispy. Going over ocicl, I don't know whether to laugh or cry. What is ORAS, "artifacts", "OCI registries" and why should I care? Why is systems.csv CSV and not .lisp? What is this 9MB binary (no source) named "oras" doing checked into the repository?
If I wanted all this enterpriseitis I wouldn't be using Common Lisp. I think that's a big strike against ocicl.
- Quicklisp -really slick, libraries in there are curated. (with https support here: https://github.com/rudolfochrist/ql-https and here: https://github.com/snmsts/quicklisp-https.git)
- for project-local dependencies like virtualenv: https://github.com/fukamachi/qlot
- a new, more traditional one: https://www.clpm.dev (CLPM comes as a pre-built binary, supports HTTPS by default, supports installing multiple package versions, supports versioned systems, and more)
For recent Quicklisp upgrades: http://ultralisp.org/
Ocicl is very new (5 days) and tries a new approach, building "on tools from the world of containers".
That model of a middleman NOT the original package author being responsible for distribution is highly problematic. A package manager today needs to maintain and make it simple to verify end-to-end provenance.
There's a sibling post with this link but it's greyed out.
The world of OCI (docker) container images has produced a plethora of great tools and services, many of which are useful beyond simple container image management. OCI-compliant registries, like the github container registry, are perfectly happy storing arbitrary artifact blobs using the same versioning, labeling and security capabilities developed for application containers images. Tools like oras, skopeo, and the sigstore ecosystem are directly applicable to OCI-registry-hosted artifacts.
ocicl is my attempt to exploit this ecosystem to manage libraries of Common Lisp code. Think of it as a modern alternative to quicklisp. It is modern in the sense that:
* all software is bundled as OCI-compliant artifacts and distributed from an OCI-compliant registry (the github container registry).
* all software is distributed over secure (TLS) connections.
* sigstore tooling is used to ensure the integrity and authenticity of all software bundles.
* all software bundles are project-local, making it easy to lock specific versions to your own projects.
* all software bundles are built and published transparently using hosted CI infrastructure (github actions).
Of course, content curation is an enormous challenge, and ocicl currently only has maybe 10% of what's in quicklisp, but you can help change that!
Many other projects claim to be alternatives to quicklisp. It's almost like developing one is a rite of passage for Lisp hackers.
1. Linux is not a niche in the target market for this project.
2. The project is written in Common Lisp with hard dependencies on SBCL-provided libraries[1], so there's reason to suspect it should work on other OSes supported by SBCL.
3. Sure, the presence of Makefile and sb-posix imply it requires a POSIX compliant OS, but Linux is not the only one that fits the bill.
4. The included Linux-only binary 'oras' is clearly a vendored artifact, not part of this project, and clearly an OCI client. A simple search shows it is indeed cross-platform[2].
Perhaps you should try what almost every Linux user has had to do when encountering software actually built for only one "niche" operating system that they want to use on their OS: look.
1. https://github.com/ocicl/ocicl/blob/170aff0/ocicl.asd#L34
I did look - at the README of the linked site, which clearly states:
> ocicl (...) only works on Linux
I don't see a reason why the author(s) of ocicle should lie to me. (If they do: even worse.)
> Linux is not a niche in the target market for this project.
[citation needed]
That's looking for the wrong thing. Us Linux users see things like that all the time: proprietary software has a download page that only lists Windows (and sometimes macOS) but never Linux.
But we don't stop there. We don't look for a reason to abandon hope (or worse, complain idly). We look for a way to run that software on Linux. And usually, it is a lot harder than this case.
>> ocicl (...) only works on Linux
> I don't see a reason why the author(s) of ocicle should lie to me.
Is it not obvious? They aren't lying. They're being clear. As they go on to say, in the very same sentence: ", but adapting to other systems and platforms should not be difficult."
If you'd looked for a way to run it on your niche operating system, like me, you'd have found an easy way. And, maybe, you could have even contributed the solution to the project, as it says two sentences after where you stopped reading and decided to idly complain in a thread on an unrelated forum.
Just two posts above this one, you claimed that downloading a different ocas binary would probably work. So ocicl does not only work on Linux, right?
I get that you probably just want to win an argument, for the sake of winning an argument, and most likely you're not actually interested in getting some software to run on your niche operating system.
But, just for the far fleeting chance that you are actually interested in doing the right thing:
1. I did not claim that the "oras" binary was the only incompatibility. I guessed your quick judgement was based on that binary being vendored for one platform only and showed that it does exist for other platforms. The latter clearly does not imply the former.
2. Ocicl developers claiming it "only works on Linux" is not a promise they make to you. You cannot hold them at gotcha-gunpoint just in case the software happens to run on a non-Linux OS. They are not interested in playing a game of gotchas with you.
They _are_ being clear: they have only tested it to work on Linux. It is you that misreads it, probably because, I'm guessing, you aren't familiar with the language of OSS READMEs
That might well be the case here. No, I don't try to win arguments on the internet. :-) Thank you.
this thread is evidence to the contrary.
I am not able rightly to apprehend what sort of world-view one has to have to complain that a LISP project runs on an incorrectly-named "niche" operating system in 2023.
(I can't believe I'm saying this, but) even Windows runs Linux now.
> How is this related to my comment?
Your comment indicates your access to computing does not include Linux. That would indeed be a niche area of computing, when intersected with the area targeted by this project, where Linux is commonplace.
Optionally. WSL2 is not (installed and) activated by default.
> intersected with the area targeted by this project, where Linux is commonplace.
I wrote none of my Lisp tools on Linux, and I never received a Linux-related bug report for those. I wonder where I can find numbers on that.
Windows also does not ship with ocicl (by default), but no one's gonna complain about that. If you'd like to install this piece of software on a Windows machine, think of enabling WSL2 as a preparatory step, like how you'd have to install MS Visual Studio / Cygwin to build Windows-only software, or install a DLL to run some Windows-only software.
> I wrote none of my Lisp tools on Linux, and I never received a Linux-related bug report for those.
Congrats. It is absolutely a good thing that you did not have to touch Linux in order to write software that (presumably) runs on Linux. Maybe the other OSes of the world can learn a thing or two about that.
And it is also good that you never received a Linux-related bug report. Presumably, your software runs flawlessly on Linux. Or, more likely, Linux users of your software know how to fix issues that may pop up and move on.
However, your limited experience of the world does not have to accurately portray how the world actually is.
> I wonder where I can find numbers on that.
The most popular implementation of CL is SBCL (ref: State of Common Lisp Survey 2020). SBCL is primarily developed and tested on Linux, and its largest industrial users also run it on Linux servers (same goes for ECL, Allegro, and LispWorks). This I know from being a (passive) participant in the CL community. I'm not sure I can get you numbers on this, but I can get you numbers that show SBCL receives bug reports for Windows far more than it does for Linux, despite Windows being one of the least tested or prioritised platform, so I'm not sure your method of judging a platform's importance is very good.