Can anybody explain the difference, pro and cons between qlot [1] and ocicl [2]?
Both Ocicl even newer than qlot but both not wide spread.
Both seem to address the problem of project-local library dependency management<p>By reading ocicls readme I don't really get the underlying mechanics.<p>Qlot I consistently had problems with getting existing cloned projects to use it.
Maybe we can share our experience here?<p>Update:
Added clpm [4] to include in comparison request.<p>Question derived from thread[3] where this discussion started.<p>[1] <a href="https://github.com/fukamachi/qlot">https://github.com/fukamachi/qlot</a><p>[2] <a href="https://github.com/ocicl/ocicl">https://github.com/ocicl/ocicl</a><p>[3] <a href="https://news.ycombinator.com/item?id=41609491">https://news.ycombinator.com/item?id=41609491</a><p>[4] <a href="https://www.clpm.dev/" rel="nofollow">https://www.clpm.dev/</a>
ocicl author here. What I'm attempting to provide with ocicl is
a) a system that is easier for "Enterprise" developers to work with (TLS by default, repos hosted on well-known domains that exist in enterprise firewall "allow-lists", well documented/supported solution for mirroring contents (OCI registry mirroring), etc). I occasionally work within secure, highly regulated environments, and it was pretty much impossible to use sbcl+quicklisp because of all of the security constraints. ocicl make this possible today.
b) a fully transparent set of tools and processes that are not dependent on Quicklisp and for which a community of maintainers could be established.
I think it's been a success on (a), and a work-in-progress for (b).
qlot is also nice if all you are looking for is a way to deal with project-local library dependencies.