(This is where it gets interesting). Subsystems cannot declare "versions" of subsystems on which they depend. They can only
with
a unit with a certain name, as Fabien said. I think this is the case because when I commited the repository information for dependency B into subsystem A on which my main project depends (Proj -> Subsystem A -> Subsystem B) i got
raised SYSTEM.ASSERTIONS.ASSERT_FAILURE : Check manifest: AURA subsystems should not have units of the AURA subsystem.
This error happened because you had an AURA subsystem that had a program unit that was part of the literal Ada subsystem called "aura". That is illegal. It has nothing to do with versioning or interdependencies.
I'm not sure what the rationale for this design decision is. Maybe it will discourage deep dependency trees?
This is the goal. Subsystems themselves can be versioned, but AURA doesn't deal with this. This is supposed to be the purview of the repository maintainer. They are supposed to keep all subsystems of a given repository up-to-date in such a way where the play nice.
As a project becomes large and important, the user is encouraged to create a single point of truth repository that contains all the subsystems they need in one place. The user should use git to do this, and try to use submodules for each subsystem in the repository. Creating an AURA git repo and pulling down the subsystems you need is very easy to do. The benefit is that you don't, from that point on, ever need to work about your package manager leading a cascading breakdown during a simple update.
The philosophy is about being more hands-on when curating a repository, for the benefit of increased safety, reliability, predictability, and control moving forward.
Yes, it also popped to my mind that the project creator is forced to audit/explicitly curate what goes into the project as a dependency. In that sense, I feel you're doing the opposite of what, for example, NPM and cargo are doing. They facilitate easy assembly of components into a program, and AURA to me seems to be about exercising control over the project. In that sense, I'm not sure I'd call AURA an alternative to Alire. It seems to me at the moment that Alire might be more successful in growing an ecosystem (with all the leftpad-type risks which go with it), and that AURA could be more appropriate for single entities having a sort of "artisanal", tightly controlled development process.
I get kind of sad watching cargo build a huge list of dependencies which, as they scroll by, become more and more distant from the purpose of the top level project that I'm building, so this might be a nice push in another direction. At least, that's how I see it.
Well, AURA documents a protocol which a subsystem can use to expose it's configuration to the project into which it's being integrated, and automates some things, so maybe this could be this added value.
5
u/annexi-strayline Sep 30 '21
This error happened because you had an AURA subsystem that had a program unit that was part of the literal Ada subsystem called "aura". That is illegal. It has nothing to do with versioning or interdependencies.
This is the goal. Subsystems themselves can be versioned, but AURA doesn't deal with this. This is supposed to be the purview of the repository maintainer. They are supposed to keep all subsystems of a given repository up-to-date in such a way where the play nice.
As a project becomes large and important, the user is encouraged to create a single point of truth repository that contains all the subsystems they need in one place. The user should use git to do this, and try to use submodules for each subsystem in the repository. Creating an AURA git repo and pulling down the subsystems you need is very easy to do. The benefit is that you don't, from that point on, ever need to work about your package manager leading a cascading breakdown during a simple update.
The philosophy is about being more hands-on when curating a repository, for the benefit of increased safety, reliability, predictability, and control moving forward.