elba is a new-ish package manager for the Idris programming language. Over the past few months, there has been slow but steady progress towards making elba a more robust package manager that can play in the big leagues. Now, around a year since the initial commit to the elba repo, I can confidently say that elba is kinda-sorta-maybe-almost there! With a new point release and a new, fancy-shmancy, extremely artisanal website, elba is now Production Ready™.

elba.pub

elba homepage

Nothing screams “production ready” like a fancy website, and now, elba has one, located at elba.pub! Work on this part of the project has been spearheaded by Andy Lok (@andylokandy) and assisted by Andrés Rodríguez (@mixedCase) - without them, there’d be no elba.pub!

The best way to learn about the website is to go browse it yourself, but the basic functionality is as follows:

Uploading a package

With a hosted server backed by Amazon S3 storage, we can store packages on a package server! Package creators can choose to upload their packages to the elba.pub repository through a fairly streamlined process:

Log into elba.pub using a Github account
Get a token
elba login <token>
cd project && elba publish

(note that package namespaces are first-come, first-serve: once a user uploads a package to a namespace, it’s theirs, forever.)

See the docs for more info.

Browsing packages

Like any other big-name package repository, elba.pub has a pretty UI which you can use to search for and find info about various packages. Each package’s README is accessible from the package’s page, along with links to other pertinent places (homepage, repo, etc.).

Additionally, package searching functionality is available from the command line. Just whack elba search <query> to fuzzy-find a package.

Depending on packages

As a package consumer, you can now just depend on a version of a package, instead of having to specify a git repo:

[dependencies]
"dcao/hello" = "0.1.0"

This also means that the Pubgrub dependency resolution system which elba uses will finally be put to use, ensuring that dependency resolution is fast and produces pretty error messages.

elba’s versioning system has its own idiosyncrasies which you might want to familiarize yourself with: as always, the docs are your friend.

The 0.3.0 release

If you want a brief list of everything changed with 0.3.0, feel free to take a gander at the changelog. Rather than enumerate every single change here, I’ll note larger improvements.

Improved registry functionality

In order to coincide with the release of elba.pub, elba-the-cli has a bunch of new subcommands and manifest fields for interacting with package registries; this includes the ability to publish and yank packages, search through packages in an index, and login to a package registry.

Scripts and hooks

With this release, packages can now declare scripts, which are arbitrary shell commands runnable in the project directory via elba script <script_name>:

[scripts]
prebuild = "echo 'I'm building now!'"
fail = "exit 1"

Additionally, certain scripts (currently only prebuild) are automatically run during the build and install process; these are called hooks, and they can make for some pretty powerful behavior. For instance, if you want to check for the presence of a binary on a build system, you can do so with the prebuild hook, exiting with a non-zero return code to error out of building this package.

Experimental Blodwen support

This release adds some basic support for Blodwen (aka Idris 2). A new config variable, compiler, has been added. If you set this to the path of a Blodwen executable, elba will switch its build process to be Blodwen-compatible. However, due to restrictions with the Blodwen compiler, there are some caveats:

elba repl doesn’t work due to the inability to add multiple source paths
Doc generation doesn’t work
Codegen doesn’t work (i.e. you can’t build binaries)

This release also lays the groundwork for more robust Idris 2 support in the future. For instance, this release has added the concept of a “virtual package,” which has no build targets. In the future, a virtual package idris/idris could be created, with different versions of the package checking for the presence of a certain version of the compiler via hooks.

In sum

Now that elba has these two pieces of infrastructure in place, elba is much more capable of properly handling the Idris package ecosystem. So go forth and code! In the future, I expect even more improvements to come through the pipeline (including in the far future, rewriting elba in Idris!), so stay tuned!