Frequent Questions

How should “Fury” be written?

”Fury” (when describing the build tool or project) is a proper noun, so it starts with a capital letter. The command and package name, however, are fury.

Does Fury support plugins?

Fury has no dedicated support for plugins, but the same functionality is available by other means, typically through application modules which run during a build. Some functionality traditionally provided through plugins may, in the future, be fully merged into the build tool.

Can Fury cross-build to different versions of Scala or different platforms?

Yes. Fury provides schemas as a means of specifying a number of variations of an entire layer of projects, which are broadly identical, but differ in key aspects such as their choice of compiler, included dependencies, source directories, repository commit hashes, and indeed, any aspect.

Schemas differ from entirely independent layers in that Fury is designed to make it easy to make changes to all schemas concurrently, and to view differences between them.

Can Fury build with Scala 3 (Dotty) projects?

Yes, it can compile Scala 3 projects and mixed Scala 2/3 projects.

Can Fury build Scala.JS or Scala Native code?


Are Fury builds repeatable?

Presently no, in the sense that there are no guarantees that multiple runs of the same build will produce identical binaries, but the intention is that they should be. No effort has yet gone into this. Furthermore, any builds which are defined with application modules may run arbitrary code during building, which is a potential source of nondeterminism. Authors of such builds would need to adhere to certain constraints for builds to be repeatable, but that decision is left to the authors.

Can I publish binaries to Maven Central with Fury?

Currently this is not possible, however there are designs for how this would work. Publishing a project to Maven Central requires that any dependencies of that project are already published, and this does not fit well with Fury’s fine-grained model of source dependencies.

However, it would be feasible for a library maintainer to maintain a schema for a build which uses a choice of binary dependencies in place of source dependencies. Such a schema, if maintained alongside the primary source-dependency-based schemas, could form the basis for publishing.

Is Fury intended to replace sbt?

Fury should be able to serve as a replacement for sbt for individual projects for many—but probably not all—build tasks and workflows. Fury is currently very good for orchestrating compilations, but is not intended to perform many of the tasks around that, which sbt is commonly used for, particularly the sort of functionality provided by sbt plugins.

More generally, at some later time, once it has a more complete feature-set, Fury may potentially replace sbt as the de facto build tool for Scala, but it has no designs on how this would happen, beyond trying to offer an enhanced user experience for individual users.

The early goals of Fury are to embrace the source distribution model, in parallel with the current ecosystem of binary distributions so that the benefits of this may be realised as soon as possible.

If I have a contribution to make to Fury, can I expect it be merged?

Once Fury is open-sourced, there is much hope that it will become a project which is actively developed and maintained by many different developers, and accepting contributions will form a large part of that. It does, however, already have a clear vision for how many planned features should be implemented, and it is strongly recommended to discuss any significant contributions with Jon Pretty before embarking on any development work, or risk that they be rejected.

When will Fury be released?

Fury will be released in 2019.

Why is Fury not available already?

Fury is currently in development, and shared amongst a small number of private beta testers. Given that its design remains in flux, and its buildfile format may change, in incompatibe ways, caution is being exercised to avoid a premature general release which could result in the proliferation of a large number of builds which would not be compatible with later versions, leading to a degradation of the user experience for everyone, at a time when first impressions are particularly important.

Can I use Fury to generate code during a build?

Fury allows application modules to compile and run code during a build. This code can perform a number of different tasks, including generation of code. An application module will have its main method invoked with the JVM working directory set to the root of the build in which it is defined. The JVM should exit with a zero exit-status if the build should continue.

Can I run tests with Fury?

Fury has no special support for running tests because this functionality is provided in a more general way through application modules. An application module is a module which, as well as being compiled during the build, is also run by calling a main method.

By defining a main method in a test module which depends on the modules to be tested, plus any testing libraries or frameworks, Fury can run unit tests (or integration tests, or any other sorts of tests) without the need for special support.

Why does Fury prefer source rather than binary dependencies?

There has been much debate over whether source or binary dependencies offer the best user experience for development in a changing ecosystem. The task of designing libraries for source and binary compatibility was explored in depth by Sébastien Doeraene, in which he concludes that binary dependencies are a difficult, but nevertheless possible, solution to managing compatibility between different versions of software.

Source dependencies have two significant advantages over binary dependencies, however.

Firstly, when compiling from source, the compiler will perform all the necessary checks to ensure (ignoring potential bugs in the compiler) that linking errors will not happen at runtime; we are made aware of problems prior to runtime.

Secondly, source dependencies provide a means to fix the problem; we can modify the source (and if the solution is generally useful, we can create a pull-request back to the original project). Whilst it may not always be a good idea to fork either a project or its dependency in order to resolve incompatible version mismatches, it remains possible with source dependencies.

When managing a build with Fury, dependencies will typically be managed by Fury, inside a hidden directory. But it is as simple as running a single command to fork a dependency out of Fury’s control into the user’s layer, and to start to make changes to it.