A Clojure library designed to provide common functionality for Clojure
development tools (e.g. Clojure editor plugins and IDEs).
orchard provides functionality like:
- enhanced apropos
- classpath utils (alternative for
- value inspector
- Java class handling utilities
- Utilities for dealing with metadata
- Namespace utilities
- Fetching ClojureDocs documentation
- Finding function dependencies (other functions invoked by a function) and usages
Much of the tooling code required to build Clojure editors and smart REPLs
is tool-agnostic and should be reused between tools, instead of copied
and altered in each and every tool.
Having a common tooling foundation typically means:
- Better foundation (e.g. more functionality, good documentation, etc) with more contributors
- Less work for tool authors as they don't have to reinvent the wheel for every tool
- Happier end users
Orchard is meant to be used to build programmer tooling relying on inspecting the state of a running REPL.
REPL-powered tooling has been a core Lisp idea for many years and there are many Clojure libraries
in that space (e.g.
One thing to keep in mind is that Orchard relies (mostly) on runtime information, not the source code itself.
In simple terms - only code that's loaded (evaluated) will be taken under consideration. That's pretty different
from the static analysis approach taken by tools for most programming languages where it's not possible to
easily inspect the state of running program.
Some other design goals are listed bellow.
Orchard is meant to run alongside your application and we can't have a
dev tools library interfere with your app right? Dependency collisions are nasty problems which are best solved
by making sure there can't be any shared libraries to cause the conflict.
Code editors can't know what symbols resolve to without consulting a REPL that's why they would typically
send a combination of a symbol name and some ns (e.g. the current namespace), so they can be resolved to
some var on which an operation would be invoked.
That's why the majority of the functions in Orchard take a combination of a ns and a symbol instead of a var.
Probably down the road we'll provide var-friendly versions of most functions as well.
No matter whether you're using nREPL, a socket REPL, unrepl or prepl, Orchard has your back. nREPL clients might
opt to wrap some of the Orchard functionality in middleware for convenience (as
cider-nrepl does), but they
can just eval away if they please.
Documentation for the master branch as well as tagged releases are available
orchard requires Clojure 1.8+ and Java 8+.
orchard as a dependency and start hacking.
Consult the API documentation to get a better idea about the
functionality that's provided.
There are features that Orchard intends to provide (especially, those related to Java interaction) which need to assume a pre-existing initial classpath that already has various desirable items, such as the JDK sources, third-party sources, special jars such as
tools (for JDK8), a given project's own Java sources... all that is a domain in itself, which is why our enrich-classpath project does it.
For getting the most out of Orchard, it is therefore recommended/necessary to use
enrich-classpath. Please refer to its installation/usage instructions.
These functions use a Clojure compiler implementation detail to find references to other function var dependencies.
You can find a more in-depth explanation in this post.
The important implications from this are:
- very fast
- functions marked with meta
:inline will not be found (
- redefining function vars that include lambdas will still return the dependencies of the old plus the new ones
- does not work on AoT compiled functions
So far, Orchard follows these options, which can be specified as Java system properties
(which means that end users can choose to set them globally without fiddling with tooling internals):
false, the class info cache initialization may print warnings (possibly spurious ones).
To run the CI tasks locally use:
make test cljfmt kondo eastwood
Originally SLIME was the most
popular way to program in Clojure with Emacs and a lot of useful
functionality was created for it to support things like code
completion, value inspection, finding references, apropos and so
on. This functionality was implemented as a swank adapter written in
Clojure and lived in the
Subsequently CIDER and
SLIME and swank, and much code was moved from
cider-nrepl and continued to evolve there.
You can watch the presentation The Evolution of the Emacs tooling for
to learn more about all of this.
This project is an effort to prevent repeating the mistakes of the
cider-nrepl was split into two libraries, so that non-nREPL
clients can make of use of the general functionality contained in
cider-nrepl (e.g. things like
enrich-classpath is important for development of Java-related features in Orchard, since it makes the Java sources available. Certain features parse those Java sources as a source of information.
You can fire up a repl (and nrepl server) that uses cider-nrepl and enrich-classpath like so:
# or `make lein-repl`
You can install Orchard locally like this:
PROJECT_VERSION=0.22.0 make install
For releasing to Clojars:
git tag -a vX.Y.Z -m "Release X.Y.Z"
git push --tags
Copyright © 2018-2024 Bozhidar Batsov & contributors
Distributed under the Eclipse Public License either version 1.0 or (at
your option) any later version.