when writing a clojure library, should we just have all the dependencies declared as :provided?

I tend to make deps that are not strictly needed for the library to be usable provided.

An example would be in clj-http that cheshire is not strictly needed, unless you want to do json parsing

Sometimes people make these part of the test / dev dependencies. I think provided is the intended use for this.

nice thanks, I'm trying to add a library to a project now, and I get a million conflicts like [io.confluent/kafka-schema-registry "5.1.0" :exclusions [org.slf4j/slf4j-log4j12]] -> [io.confluent/rest-utils "5.1.0"] -> [org.eclipse.jetty.websocket/javax-websocket-server-impl "9.4.12.v20180830"] -> [org.eclipse.jetty.websocket/javax-websocket-client-impl "9.4.12.v20180830"] -> [org.eclipse.jetty.websocket/websocket-client "9.4.12.v20180830"] -> [org.eclipse.jetty/jetty-client "9.4.12.v20180830"] -> [org.eclipse.jetty/jetty-http "9.4.12.v20180830"]

the actual version numbers from the main project will however still take precedence right?

would be nice to just exclude everything for that library

the ones you define in your own project take precedence, I think

e.g. if your main project says clojure 1.10, but a lib says clojure 1.9, you will get 1.10

When deps A and B bring along distinct versions of C it's not too hard to exclude C from one or the other or to state a direct dependency on one particular version of C. The problem is, what happens later?! When updating A or B, will you notice the extraordinary measures, back them out, and reintroduce only if necessary? Or will your project stay forever pinned to C-version-1 long after A and B have moved on to C-version-6?

A deps-resolver syntax that makes clear both the problem and the solution, and applies the solution only when circumstances match the stated problem, would allow tidier engineering

yeah it's a fun problem in every ecosystem really

btw is there a library to generate a graph of the dependencies (with graphviz) that works?

vizdeps seems to be the best one but it's not working anymore, and I could not really find one that works apart from that

Often wondered if (at least on the JVM), it would be possible to isolate all this stuff with some classloader magic. One CL for each dep and a CL graph that mirrored the dependency graph etc. There's a fun project for somebody who gets bored.

@wesley.hall Maybe boot is already doing this with pods

Oh, I didn't know this. Will investigate. Thanks.

Hi! How can you match all routes with a specific prefix in Bidi? e.g. match all routes that start with /app. So all routes of the form /app/*/*...

nevermind, the answer was true (https://github.com/juxt/bidi/blob/master/README.md#catch-all-routes)

I am trying to implement clojure.lang.ILookup in a record like this

(defrecord StaticMapService [m]
  sim/Service
  (start_service [this process] this)
  (finalize_service [this process] this)

  IFn
  (invoke [_ ident]
    (get m ident))

  ILookup
  (valAt [_ k] (get m k))
  (valAt [_ k not-found] (get m k not-found)))

Records already implement ILookup

If you want custom lookup behavior you need to drop down to deftype

oh so I can just merge upon start_service

thankyou

Yes, should be able to

Is there a nice clojure lib to go back and forth between UUIDs and base62-encoded (or similar) UUIDs? (to put in URLs)

There’s the built-in murmurhash (https://github.com/clojure/clojure/blob/master/src/jvm/clojure/lang/Murmur3.java) - not sure if it would fit the requirements

I would consider that an implementation detail of Clojure and not something to rely on calling into

ah - good to know!

i have something not quite understood while reading Clojure Programming (it's really a great book) it explain one of the usage of recur is when performing mathematical operation. > In addition, because it allows you to work with numerics without the overhead of boxed representations, ... what overhead of boxed representations means?

http://insideclojure.org/2014/12/15/warn-on-boxed/

ah, it was a java stuff

Hey guys! In clojure jdbc, I am trying to understand :return-keys How can I get only [{:a … :b ...} ...] returned?:

(db-do-prepared-return-keys
  db
  (into statement updates)
  {:multi? true
   :return-keys {:columns [:a :b]}})

:return-keys [:a :b] didn’t work for me either

if I recall the behavior of return-keys is highly database dependent

I don't think :return-keys is actually an option you can set on db-do-prepared-return-keys

it always returns keys

ok

db-do-prepared-return-keys calls prepare-statement with return-keys set to the boolean true, regardless of any options passed in

you can change that by calling prepare-statement yourself and passing that in

the prepare-statement docstring has a blurb about the behavior being driver dependent

ok, thanks

ok, I can do :row-fn #(select-keys % [:a :b]) though

interesting

@leontalbot It looks like you only want to select specific columns. In that case you should do that in your SQL statement (instead of SELECT * FROM do SELECT a,b FROM ...). The purpose of :return-keys is to get keys generated by inserts from the DB.

@jkr.sw my statement is an UPDATE one though

@leontalbot :return-keys can accept a vector of column names on some (but not all) databases. You should not use db-do-prepared-return-keys really -- it's very low-level (and, I think, assumes you already have a PreparedStatement -- where you would have set those options prior to calling it!).

insert! and execute! should accept :return-keys with a vector (if your DB allows it).

Also, there's always #sql for deeper clojure.java.jdbc questions (I'm more likely to see it there).

ok changing channel

@hmaurer I use a very nice library by @tonsky that produces compact 26-char UUIDs: https://github.com/tonsky/compact-uuids

i thought i remembered ghadi making or showing off someone else's uuid -> words library? does that ring a bell with anyone

ill post a gist of that, https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki is the spec

If I wanted to hook into an existing protocol on a built-in type to provide some additional functionality, is there a better way than wrapping the protocol's method I want to extend?

well, there are no protocols or methods there

(there are protocols and methods in the implementation of the object passed to swap!, and swap! itself is an object extending IFn but I don't think that's what you mean)

but if you mean generally, you want to do an AOP style wrapping of an existing function, yeah that's what it typically looks like

though idiomatically wrap-foo means "hand this thing a function, it returns a new one", which isn't your semantics here, but that's a naming issue

poor choice of nomenclature on my part... I basically just mean if I have a type that implements a protocol, and I want to do something extra with one or all of the functions implementing the protocol on that type, is that the best way

yeah i named it wrap but it's more a passthrough method, agree on the naming

I don’t think protocols have anything to do with your question?

@markw once again that's not a method

method and function aren't interchangeable in Clojure, they mean specific things and we use both

i didn't literally mean method, sorry... "passthrough methods" is just naming convention for functions (or methods in other languages) that do nothing but delegate to another function

sure, most AOP style wrappers will take the original function and then use apply with a variable arg list like in your code

more commonly the function itself is passed as one of the args, which makes the wrapper more reusable (one reason functions are more flexible than methods)

@markw this is also visible in the signature of swap! itself, and alter-var-root - the function signatures make it easy to pass in a function that exists already, and return an "enhanced" version

I noticed that actually...

oh, and I don't know why a is in your function signature there - it's valid to call swap! with a single arg function, and your definition makes that impossible

Hi! Is there a clever way to convert this {:sku [111111111 22222222], :storeId 88888888} to this {:sku 111111111 :storeId 88888888}, {:sku 22222222 :storeId 88888888}?

@alexmiller Stepped away for a minute... you're right I guess the question is less about protocols and more about conrete implementations. Maybe an example would be better than me fumbling around with incorrect terminology: If I have a single-function protocol implemented concretely by several different objects, and I want to inject some minor changes to one of the implementations (and don't have access to the code to modify it directly), is wrapping the way i've described generally the best way to go about that? From an OO perspective, I would just subclass and then override the method of interest, do whatever extra stuff I needed to do, and then call the parent's overriden method from the child.

again, I don’t think the fact that this is a protocol function makes any difference

if there is a function, and you want stuff to happen before that call, wrap it in another function

Clojure intentionally abstracts invocation over functions, multimethods, protocol methods, macros (with asterisks), collections that are invokable, etc so that callers don’t know or care

in general in the core team we take it as a rule of thumb these days to wrap all protocol function invocations in an outer function that gives you a hook to handle special cases

for example, clojure.datafy/datafy is a wrapper function that calls clojure.core.protocols/datafy

protocols are best at the bottom, not at the top

OK thanks for the clarification.

if you want something that swaps atoms differently, you can wrap swap! to get a new function, if you want a new thing that swaps differently than an atom you can implement IAtom, and that implementation could even be done compositionally by allocating and using an atom internally

but good usable clojure code tends to wrap functions when possible, rather than extending protocols