read has a :read-cond option.

Okay, thanks, will check that out!

Note that clojure's read doesn't let you control the features. For this it's probably better to use tools.reader or edamame: https://github.com/borkdude/edamame#reader-conditionals

Thanks!

Oh, wait read does let you control the features, but there was something edge-casey with this: in Clojure's read you can't disable the :clj feature or so

user=> (read-string {:read-cond :allow :features #{:cljs}} "#?(:clj 1 :cljs 2)")
1

Perfect! Thanks.

No, that wasn't perfect. Check the difference.

$ clj -Sdeps '{:deps {borkdude/edamame {:mvn/version "RELEASE"}}}'
user=> (require '[edamame.core :as e])
nil
user=> (e/parse-string "#?(:clj 1 :cljs 2)" {:read-cond :allow :features #{:cljs}})
2

Okay, will try it out!

If you just want to read all the forms and you don't care about alias resolving, you can do this:

user=> (e/parse-string-all "[1 2 3] #?(:clj 1 :cljs 2)" {:read-cond :allow :features #{:cljs}})
[[1 2 3] 2]

but not 100% sure how you are using the reader for polylith

Will fiddle with it, but thanks.

Your read-file will currently only partially read this file:

(ns foo (:require [clojure.set :as set]))
::set/foo
123

No, that’s not my intention. But users haven’t reported this as a problem. If the file only contain def/defn/defmacro + comments, then it works. But I guess it would be good if it doesn’t crash in the example you give.

Here is an example how you can parse ns forms more accurately and then resolve to the right keywords, etc https://github.com/borkdude/edamame/blob/master/examples/auto_resolve.clj If you don't care about the "right" keywords, but keep reading, you can just do this:

user=> (e/parse-string "[::foo ::str/foo]" {:auto-resolve name})
[:current/foo :str/foo]

How would the code look like if I want to read from a file? (I can probably figure that out, but sometimes it’s tricky)

I mean, should I read the whole content of the file and convert it to a string and then do e/parse-string, or should I read the file as a stream or something (haven’t looked in the doc yet).

you can do two things: first create a reader with e/reader and then call e/parse-next on it repeatedly, or slurp the file and then call e/parse-string-all

Thanks!

It worked perfectly! Thanks again for the help (I used e/parse-string-all).

I configured parse-string-all https://github.com/polyfy/polylith/blob/6214667cf1493f57f19cace122c761bd1fc85a42/components/file/src/polylith/clj/core/file/core.clj#L110-L121 way and I’m now able to read the whole Polylith workspace with it. You may take a quick look @U04V15CAJ to see if I got it right! It’s important that I can read all variants of valid .clj source code, so maybe there are more options I need to add (or maybe some I should remove).

I’ll take a look later today

@U1G0HH87L This looks ok. With the newest edamame you can also use :auto-resolve-ns for better keyword reading like ::alias/foo . What are you doing with the results? For closer clj defaults, also check here: https://github.com/borkdude/edamame#clojure-defaults

I’m extracting the :require statements from the ns for .clj files + reading .edn files (which reading everything from). I added :auto-resolve-ns to the list of attributes and it worked!

@U1G0HH87L Ah then you are in luck, since edamame now also has a edamame/parse-ns-form function which returns the :requires

user=> (e/parse-ns-form '(ns foo (:require [foo :as bar])))
{:current foo, :meta nil, :requires ({:as bar, :require true, :lib foo}), :aliases {bar foo}}

It also supports gnarly edge cases like nested libspecs:

user=> (e/parse-ns-form '(ns foo (:require [foo [bar :as bar]])))
{:current foo, :meta nil, :requires ({:as bar, :require true, :lib foo.bar}), :aliases {bar foo.bar}}

Sounds great.

We started building something like this, but are nowhere near it being useful for our one usecase. The problem I see with it for the Luminus stack is, that it roughly can pull in everything. Different SQL drivers, XTDB, Datomic, spec, malli, reitit, hiccup, selmer, re-frame…

try -Sthreads 1

Thanks for such a quick reply! That is worst issue. Other issues is that it downloads all jars not just the jars for my current platform.

for that second issue, what is a maven coordinate that demonstrates that?

org.bytedeco/opencv-platform {:mvn/version "4.6.0-1.5.8"}

Last issue opencv only has a c++ interface making dynamic binding via jna and friends impossible leading to issues like this 🙂

I just opened an AskClojure issue with it. https://ask.clojure.org/index.php/12730/error-could-acquire-write-lock-artifact-org-bytedeco-opencv It was logged in Jira. Interestingly it happened only on "slow network"

I use arch, clojure cli should be up to date and can be installed via pacman

@U0LAJQLQ1 I like Arch, I've been using it for a good time back in the day when I was using Linux as my main OS.

These days I use Ubuntu for my images though.

if you are using docker, you probably do want to specify the version number for clojure cli in your build process

And there's some old Clojure https://packages.ubuntu.com/lunar/clojure

This is Ubuntu that will be released in April and has Clojure 1.10.

Ubuntu is hell

I'm using Docker actually.

I use Ubuntu on my servers, and I'm pretty sure it's one of the main reasons why docker is popular

I wanted not having to specify (I keep forgetting). The idea is get me latest Clojure, don't care which it is as long as it's the latest one.

if you are using docker, then hard coding a version of a dep is ideal

Before macports supported tools build, I used to run the install script used by the homebrew tap manually, https://download.clojure.org/install/clojure-tools-1.11.1.1252.tar.gz

From https://github.com/clojure/homebrew-tools/blob/master/Formula/clojure.rb

I think to get the latest version of something on Ubuntu, maybe you can use snap, or a ppa and use apt, but you can never be sure that those will give you up to date versions

@U0LAJQLQ1 what do you mean by hard-coding? Setting it as ENV at the beginning of the script? I have it hard-coded, but somewhere in the middle 🙈 https://github.com/jakub-stastny/dev/blob/literate.dev/build.org#clojure-cli

Jesus now there are so many bloody package managers.

@U7RJTCH6J cheers man! The version's right there, that'll work!

there is flat pack too, and yes there are way too many package managers on Ubuntu, and they are all bad

for hardcode, I just mean in your docker, if you build it a year from now that you would still build with the same version of clojure

On Linux in general. It's always the main + Linuxbrew/Nix, then all the new Ubuntu ones or what...I don't really follow, it just is a new thing every time and it's too much!

Use the script name without the version.

nix is the now hotness, but it's actually pretty old

https://download.clojure.org/install/linux-install.sh

or https://download.clojure.org/install/posix-install.sh for the Posix version

@U04V70XH6 perfect!

FWIW, https://github.com/clojure/brew-install/blob/1.11.1/stable.properties contains the version (and SHA) for the latest 1.11.1.x version in case that's usefl.

I'm adding a Getting Started with Clojure CLI to clojure-doc that mentions these scripts https://clojure-doc.org/articles/tutorials/getting_started_cli/ (it's a work in progress right now)

@U04V70XH6 thanks, that's very useful. Going to check it later 🙂

We have a script at work that starts off:

#!/bin/sh
if test "$1" = ""
then
  echo "Usage: update-clj.sh <version> [preview]"
  echo "-- preview is required if version is not current stable release"
  exit 1
fi
version=$1

curl -O 
read stable_version stable_sha < stable.properties
rm stable.properties

if test "${version}" = "stable"
then
  version=${stable_version}
fi
...

sh build/bin/update-clj.sh stable

https://download.clojure.org/install/stable.properties is maybe an easier url to get latest stable version info but the versionless urls above are supported

(the github 1.11.1 will break when we re-version, which is its own issue to fix some day)

(yeah, our script at work uses that "easier url" for the stable version -- I should have specified that in my comments, rather than the links, thanks!)