Home

Awesome

Ammonite Build Status Build (Windows) Gitter Chat Patreon

This is where the code for the Ammonite project lives:

If you use Ammonite and like it, you will probably enjoy the following book by the Author:

Hands-on Scala has uses Ammonite extensively throughout the book, using Ammonite to accomplish a lot of useful tasks: exploring third party libraries or writing parallel web-crawlers in the REPL, and implementing entire programming languages in Ammonite Scala Scripts. Hands-on Scala is a great way to level up your skills in Scala in general and Ammonite in particular.

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 per-commit maven artifact.

If you use Ammonite and like it, please support us by donating to our Patreon:

Developer Docs

The layout of the repository is roughly:

For more detailed information, check out the internals documentation for high-level overviews of some interesting facets of the codebase

Common Commands

Manual Testing

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:

Automated Testing

While working on an arbitrary xyz subproject, mill -w xyz.test runs tests after every change. ./mill 'amm[2.13.8].test' can be a bit slow because of the amount of code it compiles, so you may want to specify the test manually via ./mill 'amm[2.13.8].test path.to.test'.

Publishing

In general, if you land a change in main, 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.

Issue Tags

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:

And possibly:

Contribution Guidelines