java -jar /usr/local/jars/copilotd.jarGuardrails Analyzer is written in Clojure and runs on the JVM. It should work on any operating system that is well-supported by the Clojure tools deps system.
If you are using Windows then we recommend using Windows Subsystem for Linux.
You have two choices when running the Guardrails Daemon: Use the clojure command or a runnable jar.
The maven dependency for the daemon is actually a runnable jar. If you want to run it this way, then first specify
it as a dependency of any project, resolve the dependencies (which will download it), and then copy the jar file
from the maven repository cache. Usually this cache is under the path ~/.m2/repository, where
the actual artifacts can be found under subdirectories from there. For example: /com/fulcrologic/copilot-daemon/….
If you were to copy the jar to /usr/local/jars/copilotd.jar, then you’d run it with:
java -jar /usr/local/jars/copilotd.jarThe deps approach allows you to combine the downloading, version management, and execution into one simple setup. You just have to add this in your global deps file:
{:mvn/repos {"fulcrologic" {:url "https://mvn.fulcrologic.com"}}
:aliases
{:copilotd
{:extra-deps {com.fulcrologic/copilot-daemon {:mvn/version "1.0.0-SNAPSHOT"}}
:exec-fn com.fulcrologic.guardrails-analyzer.daemon.main/-main}}}
and you should then be able to start it with:
clojure -X:copilotdBe sure to use a version of the daemon that matches your copilot checker version.
A checker is a persistent process that runs the environment of your program. This is what enables Guardrails Analyzer to understand your specs, no matter how complex they are, or what strange features they may use. When designing Guardrails Analyzer we decided that it would often be best if the checker not run in your development REPL (even though it has everything the checker needs). You still need to work at full speed, and you should not have tooling interfering with your ability to start/stop your REPL, or otherwise block your normal development progress.
You may choose to run the checker in your project development REPL to reduce the number of things running, but because the checker reloads namespaces it make cause unexpected behaviors. If you run into that, change over to using the external process.
This is the trickiest part of the whole system. Problems can arise if you try to check a ns with syntax errors (the checker reload will fail). This could lead to an inconsistent state in the checker, and result in failures to analyze the code. This is a work in progress.
We were also careful to minimize the checker’s runtime dependencies, so they do not conflict with things you use. We did not want you to have to juggle the version of libraries you use in order to run Guardrails Analyzer!
The primary dependency is the most recent version of Guardrails. You cannot write Guardrails Analyzer-supported functions without that.
The Guardrails Analyzer checker for Clojure also includes the following dependencies on the classpath when you run it:
:deps {com.fulcrologic/guardrails {:mvn/version "1.x.x"}
org.clojure/core.async {:mvn/version "1.0.567"}
org.clojure/test.check {:mvn/version "1.1.0"}
org.clojure/tools.namespace {:mvn/version "1.0.0"}}Guardrails Analyzer requires at least Clojure 1.10.
These libraries tend to follow the "higher version means better" philosophy, so we hope they do not conflict with your application. Please let us know if these dependencies cause problems with starting or running the checker.
The easiest way to set up a Clojure checker is to add the following to your deps.edn:
{:aliases {:clj-checker {:extra-deps {com.fulcrologic/copilot {:mvn/version "x.x.x"}}
:exec-fn com.fulcrologic.guardrails-analyzer.checkers.clojure/start!
:exec-args {:src-dirs ["src/main" "src/test"]}}}}The src-dirs option is required, and indicates the base classpath location for any files you will
check. Future releases will derive this information automatically.
The checker loads pretty much like any other Clojure program. You use deps to configure a classpath, and then some namespace (optionally) gets loaded.
Since we want the checker to know about your specs and code it is a good idea to create a namespace that contains requires for the main bits of your application. This will cause them to all load at checker startup and ensure the checker has all the information it needs.
For example, you might create:
(ns checker-startup
(:require
[com.my-company.my-extra-specs]
[com.my-company.my-app-entry-point]))You must start the checker in your project root. You can add a main-ns key to exec-args, or include it as
a command line argument:
$ clj -A:aliases:for:development -X:clj-checker :main-ns checker-startupThe :main-ns points the checker to your project’s primary namespace, or the special checker startup namespace.
described in the prior section.
Your project should avoid doing things as top-level namespace side-effects, because that could interfere with
the checker’s ability to reload your namespaces and might otherwise run things you do not want the checker to run.
We assume you’re using something like mount or component and that
namespaces can be (re)loaded without causing harm.
|
Once you have a checker running, you’re ready to check some files! Read more about that in the various IDE/Editor integration chapters.
| The early access releases do not include Clojurescript support. Our early releases are for Clojure, but the design is built to work with any target runtime. If there is sufficient demand for Clojurescript support we have a working checker that just needs more product refinement and will be prioritized if that demand materializes. |
Can you improve this documentation?Edit on GitHub
cljdoc builds & hosts documentation for Clojure/Script libraries
| Ctrl+k | Jump to recent docs |
| ← | Move to previous article |
| → | Move to next article |
| Ctrl+/ | Jump to the search field |