Clojurians Log v2
off-topic 2026-06-26
Okay so fishing for opinions: Automatic dependency resolution should stop once you switch providers. Concrete example: guava depends on a small "internal" module. So if you were to declare both in your dependency manifest it would look like
<provider name="google.com">
<module name="com.google.common" version=".." />
<module name="com.google.common.util.concurrent.internal" version=".." />
</provider>com.google.common " and get that for free.
<provider name="google.com">
<module name="com.google.common" version=".." />
</provider><provider name="example.com">
<module name="demo.lib" version=".." />
</provider>
<provider name="vavr.io">
<module name="io.vavr" version=".." />
</provider>demo.lib depends on io.vavr. You don't get that unless you explicitly list the provider for that module. (you can get an error or a suggestion, but you dont get it for free). You can get io.vavr.match automatically because it doesn't cross a provider boundary though.
This way you have to directly interrogate your left-pads. Its not just "I have N deps" its "I depend on N people/orgs"@mauricio.szabo > and a nightmare to maintain Can you elaborate? Specifically I want to interrogate if it is a nightmare in the way i want it to be a nightmare or a nightmare in a pointless way
Essentially, you bring a dependency, but you must know if that dependency also depends on something that's not on "their own org". Then you bring each of these dependencies, but you also need to know if these transitive dependencies depend on things that are of different orgs... and so on. Essentially, it's dependency hell all over again, unless I understand incorrectly what you're proposing
Seems about right. Trust usually isn't invested in a piece of code but the people and organization behind it
This seems at the same time a sane default and a nightmare to maintain
> but you must know I'd say you are "forced to know"
it can error and say
ring.core depends on org.clojure, but does not provide it
Suggested Providers:
- > it's dependency hell all over again,
I think people mean different things when they say that
part of your working definition i think is the friction to find where to get a dependency from. I think we can still solve that - you find dependencies from an index and chances are only one provider exists for any given dependency
but the thought is to add back in friction for actually getting it from a different provider
> but you also need to know if these transitive dependencies depend on things that are of different orgs... and so on. So you don't need to know up front, but you would be forced to encounter it
I would argue that this is, by definition, not dependency hell. This just seems like another layer of static/dynamic analysis on top of whatever hell your dependencies already happen to be.
Your world gets more inconvenient but you are also more empowered by knowing what's going on behind the scenes.
Interesting idea Ethan.
It took him a long time to come around to saying anything nice about lisp, https://kazimirmajorinc.com/Documents/Edsger-W-Dijkstra-on-Lisp/index.html
it seems that docs had a hand in slowing things down for him? > (I am afraid that tolerance of inadequate texts was not my leading characteristic).
I was just made aware of https://httpwg.org/http-extensions/draft-ietf-httpbis-safe-method-w-body.html -- seems like a good idea but I imagine this will cause a lot of churn in web stack libraries and frameworks...
I already use http methods i totally made up
i consider it a challenge
All C# asp net apps:
sed/POST/QUERY/g ๐
(ok, it won't work this way but they rely on POST for everything, from what I remember)
Why not simply extend the GET. Seems simpler. But probably it's better to have a new one for the backwards compatibility. But even then -- extending GET would still be ok because only new endpoints would allow the body data.
> There's a method to his madness
Do we really need HTTP verbs? Is it not just data that could just as well have been part of the other existing data fields, defined by each project as they see fit, similar to cognitect-labs/anomalies?
New URL since they removed the WG page: https://www.ietf.org/archive/id/draft-ietf-httpbis-safe-method-w-body-02.html @soltanzadehramin Read the proposal and you'll see why they are suggesting a new verb here. TL;DR: GET can be cached but only takes query params and is limited on the size of data, POST cannot be cached but can take body params (much bigger size supported) -- QUERY can be cached and can take both query params and body params, so it fills a specific need.
{:method "MADNESS"}