Clojurians Log v2
clojure-dev
In my experiments at reading ~11K project.clj files using clojure.edn/read, I just tried doing the same replacing clojure.edn/read with clojure.tools.reader.edn/read, and got somewhat different results. No action items for anyone now -- I will probably try soon-ish to look at particular examples that give differences, to see what they are.
I looked at the tools.reader README where it lists differences with LispReader at the end, and didn't see any mentioned for the edn reader.
This is definitely semi-abusing an EDN reader, feeding it many files which weren't intended to be read by an EDN reader, so I won't be surprised if the differences are all "works as designed" here.
I would be interested in hearing about those differences. In my experience, people do all sorts of crazy stuff in their project files. My bet would be quasiquoting or something like that which I’ve seen a lot of, but I’m sure there’s weirder stuff out there.
This was part of an experiment motivated by a question asked by Alex Miller in #tools-deps channel a few days ago. The results I have so far are here, if you are curious: https://github.com/jafingerhut/haironfire
This is very cool work
Most don't do crazy stuff in their project.clj files, but I expect you experience more interesting queries from those who do 🙂
A few have joined "sharp equals" club in their project.clj files, but that is very rare.
Yes, Cursive has some horrendous black magic to be able to handle as many cases as possible. Integrating lein was the hardest thing I think I’ve done, or at least the most frustrating.
I think the other problem is that you also can’t read project.clj files without evaluating plugins. In particular, projects using things like lein-modules will probably read as EDN but won’t contain correct information.
I think you would need to read the project as EDN, then if you get no errors read the project by calling into lein, and compare those results.
@cfleming I wanted to verify that it is OK with you if I copy and paste your comments here into a README in my haironfire repository, as notes on how challenging it can be to calculate accurate dependencies for a Leiningen project. Feel free to say no, if you would prefer these words to be lost to the ether more quickly 🙂
That’s fine by me.
Got it. Thanks.
My little article won't drive any new business your way, I doubt, but I'll give you credit and link to Cursive's home page 🙂
Thank you 🙂. Every little helps.
Do you have any knowledge of whether plugins can affect the value of the :dependencies list?
That is all we are really looking for here.
isn't that how the lein git deps stuff works?
Yes, they do - check the lein-modules example.
As a plugin, you mean?
There’s an example at the bottom of the readme. It allows "_" to be used as a placeholder for the version, and that then comes from a separate map. I believe in the case of submodules, the version map may actually be in the parent project, not the submodule itself, so the project.clj of the submodule is not fully self-contained.
My quick hack analysis code did check for whether version number strings were in the dependencies, or not. I was also only looking for project.clj files in the root directory of the git repo. About 8% had no project.clj file in the root dir, nor deps.edn, and I wasn't looking in subdirectories.
yeah
Of those 8%, a bit over half of those had build.boot files in root directory, and may not have had any use of Leiningen at all.
I actually didn’t know that was a thing. Looks like there’s this, which isn’t actually a plugin, it’s a task which just downloads the code, and you have to manually add extra source roots to refer to it: https://github.com/tobyhede/lein-git-deps
There’s also this, which is a plugin: https://github.com/reifyhealth/lein-git-down
I was actually thinking of the latter
I think there is also another that is newer (post clj) https://github.com/RickMoynihan/lein-tools-deps