Aura – The Ada User Repository Annex

The interesting concept, or design of this particular package manager for Ada (over Alire, which is influenced by Rust), is that the current authors have designed the AURA to be an Annex to the Ada Standard, which conceptually, histrorically, and technically makes sense, as Ada was engineered from the early days to express all software engineering paradigms in the language, and not the compiler.

>For primarily these reasons, and spurred by our own urgent needs, in late 2019 we started to work on the concept of AURA - the Ada User Repository Annex. Our goal was simple, but specific: to build a native package manager and build system for Ada. >It turns out, as is often the case, we weren’t the only ones getting this idea. And sometime shortly after we began working on AURA, another Ada package manager ALIRE appeared.

I remember hearing about ALIRE for the first time in 2018, and it seems to have been created a year before that: https://github.com/alire-project/alire/commit/eee18e0eeae46c... .

>We quite strongly disagree with the approach ALIRE takes. We feel it is too "me-too", and not Ada-specific enough, borrowing too heavily from Rust's cargo. It doesn't, to us, feel like a truly Ada-native solution. Tangentially, the use of the word "crates" for the unit of management does little to evoke the kind of principled self-confidence Ada normally exudes.

This feels like NIH syndrome to me. Cargo is amazing from a dev ergonomics perspective and stealing what it did right and improving on what it did wrong feels like the best approach to me.

>Looking at most popular language package managers out there, such as npm, pip, cargo, and even ALIRE, we see a common strategy of enforcing a versioning scheme via the package manager itself, and by extension, some mechanism for specifying inter-dependency version requirements. In theory this allows for any given package or project to clearly state the (minimum) required version of packages that it depends on. In practice, this means such a package manager enforced versioning scheme dooms both package authors and end users to certain conflict at some point. Anyone familiar with Node will know this pain. [...] >Clearly the typical approach of package-level versioning, particularly package manager enforced versioning is not the right way. Instead of using complex package version dependencies, we think it is better for the end user if the entire repository itself is "versioned", and through mechanisms appropriate for the repository maintainer and users. We propose that all subsystems within a repository should be coalesced into a repository-level snapshot that can be tested collectively for compatibility, and updated through a disciplined process that prevents broken dependencies.

The problem described is real, but I don't see how the suggested solution solves any of that. Having your entire repository "versioned" is equivalent to having a package-lock.json at the root of your repo. The problems are still there.

>Beyond satisfying dependencies, AURA is also designed to handle configuration of non-Ada components of the subsystem, particularly by influencing the C preprocessor, as part of auto configuration process.

That sounds very interesting.

>Traditionally the go-to Ada build tool has been gprbuild, which is very unwelcoming to Ada newcomers (or anyone, really). The "Ada-like" configuration syntax is overly complex, and the documentation is difficult to navigate.

Wholeheartedly agreed. I think ALIRE is supposed to make this easier though (I think it can generate default project files for you?).

>We designed most of these packages for use in very high-integrity, high-throughput, long-lifetime applications. Some components that process untrusted input (such as the UTF8 stream decoder) are written in SPARK, and have been formally verified.

That's very cool!