org.clojure/clojure itself is not a Git library, so you can't use find-verisons for it.

I use the command on Clojure CLI version 1.11.1.1113 without error tho

Hmm, indeed...

Seems like this commit: https://github.com/clojure/tools.deps.alpha/commit/a4ad9c23250270a173101aee6bb2eceeaee53d92

thank you, gonna look at it

Created https://ask.clojure.org/index.php/11974/regression-tools-deps-alpha-cant-find-versions-coordinates

Thanks for the report, I'll get that fixed

(And add a test!)

You can keep an empty example record and intersect with its keys

But why?

Great question! I was idly thinking about writing some helper code that could distinguish between declared dependencies in a com.stuartsierra.component component and ad-hoc fields that were added as internal implementation details.

So I suppose you want to do this in a general case and don't have these "empty" record instances around. You could try to access them as fields or even use __extmap directly: https://github.com/jumarko/clojure-experiments/blob/master/src/clojure_experiments/records.clj#L20-L21

Aren't declared dependencies considered declared with the using metadata?

@UK0810AQ2 by some people, yes. Others consider the fields in the defrecord form to be the declaration of what is required. Arguably they declare different dependency sets though. The defrecord tells you all the dependencies you might need for full functionality as defined by the code of the record itself, whereas the component/using form tells you what you are providing in a specific system map. You might for example use the same component type in more than one context. In particular, if you manually assoc some things onto a component and component/start it at the REPL then you might not have the metadata.

@U0FR9C8RZ does the solution I suggested work for you?

It certainly works. Tbh I'm not that keen on it though because "extmap" looks a lot like the kind of internal implementation detail I wouldn't want to build on. Thank you for your gist, though.

This was more a curiosity thing than something I need to build.

I also considered looking at the result of .getDeclaredFields, de-munging them and comparing them to the names of the map keys. It's using slightly more "public" data, but it still feels like a questionable hack.

I think it's perfectly fine for the kind of question you are trying to answer. If you are looking at building a tool for public use then maybe not but I wouldn't be afraid of that approach if you decide to actually build it.

(cmd)user=> (defrecord Foo [bar baz])
user.Foo
(cmd)user=> (Foo/getBasis)
[bar baz]

Ah, interesting!

I'm still trying to figure out how to actually use that if all you have is an instance of Foo - my interop is rusty

you can narrow things down using reflection too

(ins)user=> (-> (reflect/reflect (map->Foo {:a 0})) :members (->> (filter #(= (:type %) 'java.lang.Object))) pprint)
({:name __extmap,
  :type java.lang.Object,
  :declaring-class user.Foo,
  :flags #{:public :final}}
 {:name baz,
  :type java.lang.Object,
  :declaring-class user.Foo,
  :flags #{:public :final}}
 {:name __meta,
  :type java.lang.Object,
  :declaring-class user.Foo,
  :flags #{:public :final}}
 {:name bar,
  :type java.lang.Object,
  :declaring-class user.Foo,
  :flags #{:public :final}})
nil
user=>

I used clojure.reflect/reflect (comes with core) to find getBasis

if it's something done once on startup, the cost of reflection might be outweighed by the clarity it provides

(-> (reflect/reflect (map->Foo {:a 0})) :members pprint) shows all the methods, but fair warning many are stubs / error when called (map methods that java expects that make no sense on an immutable object)

it's too bad that getDeclaredConstructors for defrecord doesn't return a zero arg constructor

hmm... then all the code would have to worry about the "uninitialized" state as well as the "initialized" state...

Since comment is a macro, its contents still need to be read, which is when namespace-aliased keys are resolved. You can use the fully qualified namespace :my.entire.namespace/keyword to avoid the issue, or comment it out using ;; which is ignored by the reader.

There's a bug in JIRA for ignoring unreadable keywords within #_

Appreciate the knowledge. Thanks for the prompt delivery.

Is it a one-off task? Can't speak about CLJS, but for CLJ, I run lein pom in all our projects and then used Whitesource to run the audit. Most tools like that work just fine if they assume they're dealing with Java/Maven

ah excellent, thank you!

yeah one-off is totally fine

if you're getting audited or if this is for a tech due diligence, most likely you'll still spend hours explaining what's going on :-)

but having that report def helps

tech due dil. And yeah, I literally just came out of a 5-hour call!

good luck, I hope it all goes well!

(the toughest thing to explain was that you can't really do static code analysis on Clojure, beyond clj-kondo/other linters, people just assume that Java's solutions are standard - stuff like Sonar Qube etc)

There are sonar integrations with support for things like kondo and nvd checking btw

clj-holmes exists

the ruleset is not particularly large, but it is an option

lukasz, that pom option seems like not a bad one

I used it during SOC2 audits and when selling my biz, def worked as far as the technical part was concerned

yeah was going to add I did actually use it for getting through security review a couple times, but when I compare it to codeql + typescript definitions from GitHub for example, it's extremely light. It was accepted as sufficient evidence, but I personally wouldn't mind a bit more comprehensive suite

There's https://github.com/rm-hull/nvd-clojure which is based off of the Java DependencyCheck library

I use https://docs.snyk.io/, its exactly like https://docs.snyk.io/ 😆 although I havent checked how comprehensive the reports are (but then I havent had to do an audit) I suspect it covers a similar amount to nvd-clojure

The answer appears to be yes, though there is also refer-macros which might be more concise (according to the docs).

Agreed, don't think it's particularly obvious at all

Yup, definitely worth a read. I think the portion about laziness might get me over some confusion as well.

I was also surprised, at first, that vectors don't implement ISeq (it's not to say that there aren't very good reasons. there are).

there's also some background here, https://clojure.org/reference/lazy

Can't say I know any language very well outside of Clojure. Up until recently I just wrote code for fun.

so java has iterators for traversing collections, like if you have a set in java, and you wanted to process each element in it, you could do it like

... it = theset.iterator();
while(it.hasNext()) {
  whatever(it.next());
}

you can uses iterators in clojure like

(let [it (.iterator theset)]
  (while (.hashNext it)
    (whatever (.next it))))

or in in a way that consumes stack space, but will make the pattern clearer

((fn thisfn [it] (when (.hasNext it) (whatever (.next it)) (thisfn it)) (.iteator theset))

or with a seq instead of an iterator

((fn thisfn [s] (when (seq s) (whatever (first s)) (thisfn (rest s))) (seq theset))

seqs are a view for iterating over some data (often a collection), like an iterator

OK, now I'm showing some lack of understanding. What is the relationship between calling .hasNext .Next, loop/recur and peek/pop? I struggle at times with doing things like that and often write code, change, write more, until I accidentally get things working.

a java iterator is a mutable cursor, hasNext asks if there are more items, next returns the next item and moves the cursor forward one

those things don't relate to loop/recur (looping) in any particular way, except that usually when you use an iterator you are looping over calling those methods

peek and pop are functions on stacks (both lists and vectors are stacks)

To make it practical, a good pattern to practice would be loop/recur with peek and pop which will cover me for my sequential needs?

no

peek and pop work on stacks (lists or vectors), so they will cover you for stacks, but it is much more common to be using seqs, which is done with first and rest

double damn

ok, first and rest I use quite frequently.

I'm following this code until I get to theset.

((fn thisfn [s] (when (seq s) (whatever (first s)) (thisfn (rest s))) (seq theset))

running example, supposes a set collection

You've been a big help. Right now I'm writing a function to store vectors and lists in Datomic. I've been naming my attributes and functions as seq, :seq-index :seq-value :seq-type. What would you name it in place of seq to be more accurate?

How are you storing a vector in datomic?

Everything is a string, with the type annotated, maps are stored with a ref-many attribute of entries containing keys and vals annotated with a type attribute, vectors/lists are stored with ref-many items annotated with an index attribute. Nesting is done by making additional passes to replace the string collection value with a ref. Largely because I couldn't figure out how to postwalk or do anything clever. It's all fairly simple, no magic.