|Number of watchers on Github||1578|
|Number of open issues||57|
|Average time to close an issue||9 days|
|Average time to merge a PR||5 days|
|Open pull requests||41+|
|Closed pull requests||28+|
|Last commit||almost 2 years ago|
|Repo Created||about 5 years ago|
|Repo Last Updated||almost 2 years ago|
|Organization / Author||lihaoyi|
|Do you use Ammonite? Leave a review!|
|View open issues (57)|
|View Ammonite activity|
|View on github|
|Fresh, new opensource launches 🚀🚀🚀|
Trendy new open source projects in your inbox! View examples
This is where the code for the Ammonite project lives; Both:
If you want to learn more about Ammonite or how to use it, check out the links above, or ask on the Gitter Channel. The remainder of this document is developer-docs for people who want to work on the Ammonite source code itself.
If you are interested in living more
on the edge, we also publish artifacts
and the doc-site every commit; the doc-site is available at
And contains instructions on how to download the per-commit executable or depend on the perf-commit maven artifact.
The layout of the repository is roughly:
amm/is Ammonite's core, REPL and script runner
terminal/is the JLine re-implementation used by Ammonite-REPL to provide syntax highlighting and multiline editing
readme/is the source code for the Documentation, written in Scalatex.
published/is a synthetic project used for publishing, excluding the readme and integration tests
For more detailed information, check out the internals documentation for high-level overviews of some interesting facets of the codebase
Although most features should be unit tested, it's still useful to fire up a REPL from the current codebase to see things work (or not). There are a variety of shells you can spin up for testing different things:
sbt ~terminal/test:run is useful for manual testing the terminal
interaction; it basically contains a minimal echo-anything terminal, with
multiline input based on the count of open- and closed-parentheses. This lets
you test all terminal interactions without all the complexity of the Scala
compiler, classloaders, etc. that comes in
sbt ~amm/test:run brings up the Ammonite-REPL using the source code in the
repository, and automatically restarts it on-exit if you have made a change
to the code. Useful for manual testing both of
amm/ as well as
since you can just
import ammonite.ops._ and start using them. Note that
this does not bring in filesystem utilities like the
command. You can also pass in the path to a
.sc file to run it using
Ammonite's script runner
sbt ~shell/test:run brings up a fully-loaded shell with all filesystem
cd!, autocomplete for filesystem paths, and more.
readme/resources/example-predef.scala instead of your default
predef, for easier experimentation and development.
sbt ~integration/test:run runs the trivial main method in the
subproject, letting you manually test running Ammonite programmatically,
sbt ~integration/test:console brings up a console in the
subproject, loading Ammonite-REPL as a test console, as described in the
readme. Similar to
integration/test:run but useful for verifying the
different classloader/execution environment we get by starting Ammonite
inside the Scala REPL doesn't break things
sbt ~amm/test:assembly creates an assembly at
that you can then use to test: start a REPL, run scripts, etc. in a standalone
environment without being wrapped in SBT.
While working on a arbitrary
sbt ~xyz/test runs tests after every change.
amm/test can be a bit slow because of the amount of code it compiles, so you may want to specify the test manually via
amm/test-only -- ammonite.TestObject.path.to.test.
ops/testtests the filesystem operations, without any REPL present
amm/testtests the Ammonite-REPL/Script-runner, without filesystem-shell integration.
terminal/testtests the readline re-implementation: keyboard navigation, shortcuts, editing, without any filesystem/scala-repl logic
shell/testtests the integration between the standalone
amm/projects: features like
wd, path-completion, ops-related pretty-printing and tools
integration/testkicks off the integration tests, which bundle
shell/into their respective jars and invoke them as subprocesses. Somewhat slow, but exercises all the command-line-parsing stuff that the other unit tests do not exercise, and makes sure that everything works when run from
.jars instead of loose class-files
Publishing is automatic, controlled by scripts in the
Every commit that lands in master will publish a new
that you can already use and download. This includes publishing the unstable version
to maven central to the
tag, and updating the documentation-site so it's
Unstable Version download
instructions to point to it, though the
main download/install instructions
in the doc-site will not be changed.
Every commit that lands in master with a tag will re-publish a stable version to maven central and upload a new versioned release (using the tag as the version) and the doc-site is updated so the main download/install instructions point at the new published stable version.
In general, if you land a change in master, once CI completes (1-2hrs) you should be able to download it via the Unstable Version instructions and make use of your changes standalone or in an SBT project.
Occasionally, the CI job building and publishing one of the above steps flakes and fails, and needs to be re-run through the travis web interface.
I've started tagging open issues in the issue tracker to try and keep things neat. This is what the various tags mean:
Each issue should only have one of these:
bug: this behavior clearly wrong, and needs to be fixed
enhancement: something relatively speccable, that can be worked on, finished, and will make Ammonite better
wishlist: could be totally awesome, but we're uncertain if it is worth doing at all, what it would look like, or if it will ever reach a
help wanted: I don't have context, hardware, or for some other reason am unlikely to ever do this. But I know people out there care, so one of you should step up and fix it.