Fork me on GitHub

is it possible to somehow tokenize a string using specs, in a s/cat-like way? e.g.

(s/def :directory (fn [x] (re-matches ...))
(s/def :filename (fn [x] (re-matches ...))
(s/def :absolute-path (s/cat :d :directory :f :filename))
(which doesn't work for obvious reasons, but that's the idea of what i'm looking for)


actually i'm probably looking for a way to compose regexes more than i'm looking for this spec-like functionality... :thinking_face:

Alex Miller (Clojure team)10:09:15

You can do this (by seq-ing a string) but I generally think it’s a bad idea. There is actually a regex composition library for Clojure, but I’m blanking on the name


i see, that actually looks interesting


Hi. is there a generalised pattern / approach for handling config, in that a) defining the specs for the config attributes, b) documenting the individual options, c) providing default values for options? I realise this Q is a bit wide ranging, but I'm wanting to take a step back and to see what others usually do for config input


I don’t have an answer for your exact question, but I’ve spec’d CLI args before which is kinda like config Re: documentation, spec doesn’t really support it (yet?), and I probably wouldn’t use spec to influence config default values. That said, there’s probably an opportunity to pull pieces of this together into an “opinionated” config library :man-shrugging:

👍 4

Thanks @U3DAE8HMG will check this out


@U050DD55V I've done something similar for one of our applications. It's a rather hairy code and I'm sure there's a better approach for validation and replacing the invalid values with defaults but here's essentially what we've had in production for at least 1 year: See this commit which shows all relevant parts:


spec might support docstrings but probably won't support metadata, because that might cause specs to become bloated and less suitable for a variety of usecases. Because ns-qualified keywords come with no strings attached, spec is able to associate global semantics in particular contexts (when calling s/validate, for example). In a same way, maybe something like aero can maintain its own global registry of documentation, defaults etc. and be useful in contexts that make sense for it, perhaps pawning off the job of validation to spec. @U050DD55V sorry for being vague 😅 And pointing to your own library (`aero`) 😛


@U050DD55V we have an inhouse tool that we use to specify service requirements and dependencies in EDN… it’s meant to tie together CI services with what they expect at runtime etc, and help in pulling clojure services and service dependencies together across various environments… e.g. in dev you want to run the services with repls and various things set… in prod you want packer images built with config files written in the right places that define parameters to be injected into env files and config files etc. And all environments want to pull in dependent services. Anyway part of it is aero; and each service declares things like:

:omni/keys {:stardog/stardog-home {:doc "Location of the stardog home directory"
                                    :default [:install "stardog-home"]
                                    :env-var STARDOG_HOME}
             :stardog/java-args {:doc "Arguments to the JVM when running stardog"
                                 :env-var STARDOG_SERVER_JAVA_ARGS}
             :stardog/temp-dir {:doc "Java temp directory for the stardog process"
                                :env-var STARDOG_JAVA_TEMP_DIR}
             :stardog/logs-dir {:doc "Directory to write the stardog.log file to"
                                :default "."}}


which includes the doc string, and where the variable comes from etc.


so services can inform things further up the chain what they need to set; and display a useful error when something is missing