My suggestion was: add a :storm alias that has just that storm-client dependency — and remove it from your “normal” list of dependencies. Then you use that alias (along with whatever you normally use) for dev/test — and if I add a :compile-aliases option you would also pass it to that, since it’s needed for the compile part but not the main JAR-build part.

At work, we have a somewhat similar situation where we have a process that needs the standard root-level :deps alias (as in tools.deps.alpha) for a couple of actions but we don’t want it in the JAR version of that process, so we just specify -M:deps:other:aliases when we run those particular actions and -M:other:aliases when we run other stuff or build the JAR. That code doesn’t need it statically for compilation, only dynamically to run certain actions. Hence, I haven’t needed the :compile-aliases option at work yet.

Does that help @U01RKE3LQ73?

And to be clear :compile-aliases would be a new exec arg that you pass to depstar — a variant of the existing :aliases exec arg.

@seancorfield yeah that would work great

https://github.com/seancorfield/depstar/issues/75

@U01RKE3LQ73 A first cut of the implementation can be tested via

seancorfield/depstar {:git/url "" :sha "39d234b9bce94ff8f51e0660f9db8bf475618e23"}

@seancorfield thank you so much. I’ll report back tomorrow morning

@U01RKE3LQ73 FYI -- once I added tests, I found a bug, so I updated the SHA above to reflect the correction.

works perfectly!

thank you so much

I haven't figured out how to make cursive resolve linter dependencies from aliases. But that's ok for storm since it can't resolve a lot of things from storm.

I released it as com.github.seancorfield/depstar {:mvn/version "2.0.211"}.

thx for the link. i will probably use it to see how they named certain things, but i definitely won't unleash such a monstrous class hierarchy on my colleagues. imean, we are using clojure to avoid things like: OAuth2AccessTokenResponseHttpMessageConverter.setTokenResponseConverter() (i've found this on https://docs.spring.io/spring-security/site/docs/current/reference/html5/#oauth2client)

we have a ~200 LoC implementation, using http-kit, clojure.data.json and a hint of buddy-core for the sake of convenience. it's not super generic and some of the names are a bit quirky, but it's rather straightforward...

I have not even considered that Spring Security could be used effectively from Clojure :thinking_face:

@UGTAV6LR2 Yeah, the one thing I use it for consistently is DelegatingPasswordEncoder

is there a compelling reason to use Sping Sec? leaving aside its provenance, depending on a monolithic (?) solution doesn't seem very aligned with clojure ideals.

@U3JH98J4R im curious too! have u been already familiar with spring sec before u learnt clojure? @U45T93RA6 let's not forget that one of clojure's core ideas is to allow leveraging existing jvm solutions.

I'm not going to pretend to have a real scientific justification but in general for stuff like passwords and hashing i'd rather have stuff that is more well audited. Its a comfort blanket sort of thing.

I tend to program in clojure as if everyone involved in the language other than me is going to die suddenly one day choking on the dust that was once a river

JDBC stuff is stable, http stack is stable, libraries that work with just data I can alter if needed

"Security" just feels like something that would require frequent/crucial updates from domain experts. I trust the spring community for that more

Which is hypocritical, since I do use buddy for stuff

IDK, a crypto fn is essentially a mathematical function and I don't expect math to change much over time :) FWIW I'm not java-allergic (in fact the opposite) but if I can pick a lib instead of a framework, that seems a win to me auditing is also a delicate topic. A framework (even more so one written in java) seems hard to audit; often surprisingly few people know the guts of the stuff

it's not all kittens and unicorns in clojure land of course, but a smaller lib in my language of choice seems vastly easier to assess (especially for code coverage)

> a crypto fn is essentially a mathematical function Yeah, but the time taken to compute that function is an important consideration. I remember reading this a while back https://security.stackexchange.com/questions/18197/why-shouldnt-we-roll-our-own and it i think influences my opinion

There is this offhand comment in there "a scheme isn't secure until it has been extensively attacked."

and at this point i'm arguing with vibes and impressions, but it does make sense to me

at least in the manner I use spring security it is a library - it has compile time dependencies on spring but I don't think much at runtime, and I just call the java classes directly without any of that factory/bean nonsense

(def ^PasswordEncoder password-encoder
  (PasswordEncoderFactories/createDelegatingPasswordEncoder))

(defn create!
  "Creates and returns a user record."
  [db email password]
  (sql/insert! db "\"user\"" {:email (string/lower-case email)
                              :password_hash (.encode password-encoder password)}))

(defn confirm-password
  "Takes a user and a password to check to see if it is the password for the user."
  [user password]
  (let [password-hash (:user/password_hash user)]
    (.matches password-encoder password password-hash)))

(side project, not work project so I can share code)

I respect all of that :) probably the world would be a safer place if there more lang-independent test suites around for crypto, csrf, etc. Like https://github.com/nst/JSONTestSuite but for this domain Else our security boils down to trust. There isn't a categorical difference between trusting Spring or trusting a high-quality lib

Yeah, which - there is a categorical difference between stuff like buddy and https://github.com/jcf/oauth-two

no offense to jcf or his code. I can't think of any obvious things he would get wrong or can even justify oauth being an issue

but it is marked as "This project is under active development, and has yet to reach 1.0. As such the API may change." in the readme, has 4 releases, hasn't been updated in 5 years, and has 17000 downloads on clojars

thanks for the extensive discussion!

1.10.1

ah

somewhere around 1.10 there was a change to how user.clj is loaded, where loading code from user.clj could take a long time

(the change fixed it)

basically if you had a user.clj, and it loaded any core.async code it could take minutes

ah

1.10.1 was the fix

oh I didn't know that one, thanks

what prints the timing?

require prints the timing if you set *loading-verbosely*

(ins)user=> (require 'clojure.walk :verbose)
require (clojure.walk :verbose)
"Elapsed time: 0.068989 msecs"
nil

no, that's just the side effect of your alter var root

d'oh

tbc — not saying issue individual require commands. Do it in a doseq.

But you can just time each require in the standard way once they’re topo-sorted.

I am basically parsing only one string though, sorry it was not clear maybe from the example

👌:skin-tone-3: that makes sense

Still haven't solved though, cause this fails

(Paths/get "/home" ^"[S" (into-array ^String []))

ah, ok found out - no type hint in into-array

(Paths/get (:path image) ^"[S" (into-array String [])) works

[S is not a valid type hint

should be [Ljava.lang.String;

also into-array takes a class directly -- not a type hinted arg:

(into-array String [.....])

(into-array ^String [.....])

user=> (-> (make-array String 0) class .getName)
"[Ljava.lang.String;"

isn't [S an array of shorts?

user=> (type (make-array Short/TYPE 0))
[S
user=>

yup

only the primitives have single letter abbrevs

Completely misread that S here lol https://docs.oracle.com/javase/specs/jvms/se7/html/jvms-4.html#jvms-4.3.2-200 "Oh it's an S - same as the first letter of String" 😅

thank you @U050ECB92

yeah just discovered that thank you

the array stuff is what bugged me most ;)

it took me 30 mins + asking here -> I have just replaced everything we mentioned above with babashka.fs functions now 🤷

here is a more recent URL for this lib: https://book.babashka.org/#babashkafs which further points to: https://github.com/babashka/fs