Clojurians Log v2

Thanks for the reply and context borkdude. Having a lot of missing details makes it hard to discern what actually happened, but yea, that makes sense that the only constant is change and sometimes people move on.

I just wanted to say that the comment I left the other day was unproductive and wanted to apologize for it. The core desire is to see clojure grow, and I was frustrated from personal experiences of using clojure on projects with other developers (both new to clojure and experienced ones used to leiningen) who had a hard time dealing with the tooling around the language and I thought that if the tooling was made more user-friendly it could help grow the clojure community by making a positive first experience and nth experience for developers instead of one of frustration. The lack of basic error/syntax checking and reporting to users in tools.deps was one obvious way (to me) to do that, and the fact that it is unaddressed years later messages to me that this is not important as compared to other things. I know there is only so much time to get things done so the thought was that if the core were more welcoming to contributors then these sort of quality of life issues could be addressed more quickly, thus improving the experience of using clojure for everyone. However, like borkdude said, there are trade-offs in all things and I know this is the way clojure is managed and should not expect differently, but it is still frustrating when you see things that could be made better but are not, even if you understand why they are not. The desire is to help out but I know from the high profile exits of attempted clojure contributors that path is fraught. Hence the frustrated comment. Anyway, thanks for the continued work on the tooling, I'm sure it will improve over time and I know the best/only way out is through.

Providing better feedback is something we care about and looking back at the prior thread, I did do work at the time to update the specs but never got to the point of enabling it for validation. Because it was never logged it eventually fell off the plate in the usual deluge. Enhancement requests can be logged at https://ask.clojure.org and I sweep through those to make tickets at least once per week. We prioritize (partially) based on votes there. I do have a very recent ticket (https://clojure.atlassian.net/browse/TDEPS-238) that raised this again and when I next have time to work through tdeps issues it’s high on my list. I don’t think we have a good ask Clojure question related to this, so would be happy for you to write one so it can be voted on. I am happy to look at patches for stuff like this and anything else of course - we apply patches from contributors literally all the time all over the contrib projects. Re the so-called “high profile exits”, let’s just say that that summary is reductive and there’s a lot more nuance in what actually happened.

Thanks for taking the time to reply. Just posted a Q here https://ask.clojure.org/index.php/12803/tools-deps-perform-sanity-checking-on-deps-edn-file Good to know about contributions. I guess this is a grey area in community development about dealing with specific individual incidents. I specifically have in mind Tim, Zach, and Chas. All people who for many years gave a lot to the community and whose code and protocols we are still using daily. All of them had some sort of falling out that was so bad that they didn't just cut back contributing, but exited the community completely. As an outside observer it is not clear what happened and even after searching the internet for some clues it is still not clear, so all I can do is evaluate the facts that three high profile contributors all left the community after some unobserved interactions with the core team. From this vantage point in time it appears that these departures were brushed aside and largely ignored by the core team. (I don't see any public communication about what happened). As someone who wants clojure to succeed and tries to promote it to other developers it is very awkward when newcomers to the language ask what happened when they come across some old blog post or tweet about these events. I don't have an answer for them, and that led to my thoughts about contributions not being welcome. I know it can be awkward to talk about individual cases and circumstances but the lack of public communication about what happened is I think even more awkward and leaves a bad spot on clojure's history the way that unacknowledged scandals tend to in any domain. I see indirect mention to these departures in 5.3 of A History of Clojure, which from my reading, really only suggests further that you shouldn't waste your time trying to contribute to the core. I think those dramatic events of the past have helped to (painfully) align expectations about what clojure is and who it is for, but the indirect response to what happened is quite odd and I think makes the idea of wanting to contribute off-putting, but it seems like that might be by design. To be concrete, something along the lines of "some prominent contributors in the past had expectations which led them to have incorrect beliefs about the clojure contribution process, so to prevent that from happening again here are the changes that were made: xyz" I think would help provide some closure for remaining members of the community and prevent future reductive/inaccurate summaries of what happened.

I don't think everything has to do with trying to contribute to core and not getting patches accepted or so. Chas wanted to have static types and is now using OCaml. The same happened with Antonio Monteiro, heavy contributor to CLJS and author of lumo. Zach got into an interesting job at Microsoft (I believe) where he doesn't use any Clojure. Sometimes people just move on to the next thing. 🤷

I'm not saying that frustration with the contribution process doesn't have anything to do with it, but also it's probably not the whole story. But I also am an outsider to these things and don't know any details. FWIW

I've also seen people go away for 5 years and then take a peek back inside. The Onyx guy (Drogalis) went off to Confluence and kind of disappeared out of the clojure community for a while. Lately I spoke with him here again. These things happen.

Sorry, that was Confluent (Kafka)

Coming in the release later today

released

Can this be marked as a bug/feature request in tools.deps ? Is there a reason it's not allowed? Pretty terrible user experience, especially since it's a silent failure.

I think it was intentionally not supported and I'll add a check to clj-kondo for the next release, but always good to double-check with @alexmiller

Would love to hear the why - this pretty clearly breaks the principle of least astonishment

My guess would be that it's similar to why :main-opts belong to an alias: you don't always want the same set of main-opts for every invocation.

but I can easily see why global jvm opts are desirable

Whether or not it should be allowed at the top level, I suggest some error be thrown by tools.deps. This is one of those things that's small effort for the tool but provides lots of benefits for users. Especially for new users, the fact that there's not even a warning is really frustrating. Compared to user-facing tools in other programming languages it's pretty embarrassing.

well, there's also the docs ;)

If I'm not being clear, this about user experience. I think adding a sanity check to deps.edn performed by the tool itself would be a great way to improve the experience of using clojure. The way that a tool interacts with its users says something about tool itself. If it's not clear I'm saying that the behavior of tools.deps makes me think the tool is hostile to users, not welcoming or friendly. I don't think this is intended by the creators of the tool. As someone who has experienced non-clojure developers attempt to use clojure and fail, this stuff matters in changing how clojure is perceived to people who are not steeped in it.

top level jvm-opts has come up before and there's a clj-kondo issue for this reason too, so you're not wrong

This is low-hanging fruit, there is a great library waiting to be used just for this purpose https://github.com/bhauman/spell-spec

There is a ticket for this, but the reason we don’t have global jvm-opts is because you use the CLI to launch all kinds of tools as well as your application, and it seems hard for me to come up with a jvm opt that you would want applied in all those situations

What I have been considering is whether there should be a well known alias that applies for the “project classpath” context, or whether there is something even more generally useful that could serve this purpose (and others)

isn't that already what the top level is for?

maybe :replace-jvm-opts could also be an option in aliases to reset the top level jvm opts

The top level stuff is also used for -X calls

-X is made in the context of your project classpath, or am I missing something?

Yes

I’m not sure if you mean that as a pro or con :)

What I mean is, when doing -X calls, why would you not want to have the top level jvm opts (if they were supported)

Not sure, maybe you would

I also do have an issue to do more validation of deps.edn against the specs, I just need to update some of those before I enable it

I brought this up two years ago.. https://clojurians.slack.com/archives/C6QH853H8/p1639018565012400 I don't really know what to say. It's obviously an issue other people keep running into.

@danvingo I think it's good that you expressed your concern and there are issues in both tools.deps and clj-kondo about it. I'll try to get it into the new clj-kondo release, but I'm sure you are aware that each project has a backlog and it can sometimes take more than two years for an issue to be resolved because there are even more important issues to work on.

I think the reason this one may be “special” is that Java library path is more like a class path than any other opt; in this case I definitely want it on by default for this project

Wasn't there also some global environment variable for this btw? CLJ_JVM_OPTS

Maybe; I’ve been using JVM_OPTS directly since that also does what I want :D

CLJ_JVM_OPTS is only for classpath construction, not for the "app" itself

It's pretty obvious there are structural issues with the maintenance of these core projects. There's a long chain of great devs who have attempted to contribute to clojure and related core libs are now permanently absent from the community... It may seem like a digression, but the point is that if only one or two people can (practically, not technically) contribute to these core projects, they're just not going to get the attention they require for being core pieces of the clojure workflow. And the language and its community are suffering because of it. I think it's pretty cliché in the clojure community at this point, but that doesn't make it less frustrating. Again the point is that what a tool does says things about the people and community behind it regardless of the explicit words communicated. I know it's pointless to write these words as many before me have done the same to no avail, but, well, I'm frustrated with the clojure community and I think it can be useful for other people to hear that in the hope that it influences some positive changes.

there are pros and cons to how projects are managed

signcryption-demo on  main [!] via :coffee: v19.0.2 
❯ cat deps.edn
{:paths ["src" "resources"]
 :deps {org.clojure/clojure {:mvn/version "1.11.1"}
        caesium/caesium {:mvn/version "0.15.0"}
        nrepl/bencode {:mvn/version "1.1.0" :lvh/comment "netstring impl"}}

 :jvm-opts ["-Djava.library.path=/opt/homebrew/lib"]

 :aliases
 {:test
  {:extra-paths ["test"]
   :extra-deps {org.clojure/test.check {:mvn/version "1.1.1"}
                io.github.cognitect-labs/test-runner
                {:git/tag "v0.5.1" :git/sha "dfb30dd"}}}
  :build {:deps {io.github.clojure/tools.build
                 {:git/tag "v0.9.2" :git/sha "fe6b140"}
                 slipset/deps-deploy {:mvn/version "0.2.0"}}
          :ns-default build}}}

signcryption-demo on  main [!] via :coffee: v19.0.2
❯ clj
Clojure 1.11.1
user=> (System/getProperty "java.library.path")
"/Users/lvh/Library/Java/Extensions:/Library/Java/Extensions:/Network/Library/Java/Extensions:/System/Library/Java/Extensions:/usr/lib/java:."
user=>

the same string works via JAVA_OPTS

:jvm-opts needs to go in an alias

it's about time... https://github.com/clj-kondo/clj-kondo/issues/1269

Examples of using JVM options as aliases (if needed) https://practical.li/clojure/reference/clojure-cli/jvm-options/