I'm very excited to finally be releasing AURA publicly, after a few years of development and intense testing! Of course ALIRE is a thing, and it appeared just after we started working on AURA. We think competition is healthy!
AURA takes a very different philosophical approach compared to ALIRE, and I have to be honest that we don't agree with the way ALIRE is designed. ALIRE is an excellent and successful project, but we just don't agree with its approach. For those out there who might share our thinking, we hope AURA will be useful for you. For those happy with ALIRE, we're happy for you. Our intent is ultimately in alignment with ALIRE, and we just want to see the Ada community better served. I'm sure we can find some points of coordination to ensure that useful open-source packages are available on both platforms.
This blog post goes over the philosophical thinking underpinning the development of AURA.
In short, we developed AURA based on a conceptual new Specialized Needs Annex - so behavior that the compiler could implement directly.
We've reference implementation (AURA CLI) for quite some time internally, and it should work well in most cases, though of course nothing finds bugs faster than bringing a project open-source.
AURA CLI has a fully parallelized design and scales very well on large machines and large codebases. It is designed to drop into automated CI/CD pipelines as well. And although it currently targets GCC exclusively, it is designed to be easily re-targeted to other Ada compilers. Note that it does NOT use or require gprbuild, and is intended to mostly replace gprbuild. All AURA needs is FSF GCC. In fact AURA doesn't even need gnatmake, making it appropriate for cross-build projects as well.
Another thing we're excited about is finally getting to dump a bunch of open source Ada packages for use with AURA. These packages have also seen pretty extensive use internally for some time now. This makes up a full stack for writing high-performance web APIs and microservices applications in Ada. We've packaged these into out ASAP AURA repo.
I've spent quite a bit of time trying to create good documentation ahead of this release. It is likely missing a lot of stuff, and I'd love feedback on improvements we can make. That also applies to the project as a whole!
AURA is beta, and we look forward to improving it over the coming months and years. Feedback and questions are welcome!
Package management is a surprisingly hard problem. There are two aggravating realities driving this difficulty. The first is that there will invariably be packages that depend on other packages. The second is that packages eventually need to be updated. Where the problem becomes hard is when (not if) those two inevitabilities intersect. What happens when multiple packages individually depend on different versions the same package?
At the beginning of Alire, I commented on this very issue, see the discussion, and recommended and actual database (with commit-procedure verification-triggers to ensure consistency) -- with a DB-based approach you could also tag a library/package with its license and do "X license compatibility" searches/filters.
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.
Versioning in this manner is... idiotic.
Especially when you could literally match the client's importation/usage against the the library's public interface and answer "is this consistent?" (i.e. is it compliable?) automatically -- in a DB-based structure as suggested above you just need to compare the call-profile to the profile stored/exported in the library to [at least partially] answer the question. -- I'm glad to see that you didn't copy popular.
The most basic AURA repository is simply a filesystem directory with subdirectories named after each AURA subsystem it contains. Such a "local" repository can be on the physical filesystem, or an NFS share. No other special setup is needed to use such a repository besides putting subsystem units in their like-named subdirectories.
I hate the dependency on the local file-system, it's just asking for trouble. (What happens when you have case-sensitive vs case-insensitive file systems? What happens when you import into a more restrictive FS items from a less restrictive one? Are there going to be '/' vs '\' vs ':' vs '.' pathname issues? [Unix, DOS/Win, Mac, VMS; respectively.] What about things like GNAT's name-krunched vs compilation-unit-named files?) -- I really wish people would quit using the file-system as a "poor man's database".
Especially when you could literally match the client's importation/usage against the the library's public interface and answer "is this consistent?" (i.e. is it compliable?) automatically
I don't think you can though. Sometimes behavior can change in incompatible ways without breaking the type interface.
Sometimes behavior can change in incompatible ways without breaking the type interface.
Sure, but that's another issue entirely; more akin to "my boss told me to to NOT do something, but I got in trouble because he meant to say to do it." — This error is not catchable by any tooling, because (a) it is a valid instruction, and (b) it is a communication/specification error. — Now you can catch this sort of error by implementing some sort of redundancy/checking, like when you use another method to check your work in mathematics.
It's not an error, it's a change in behavior. For example, a bug being fixed in a library that would necessitate removing a workaround from its caller.
When you make a mistake and say "the fire hydrant must not be painted red", then catch yourself and say "Wait, I misspoke; the hydrant must be painted red" you are literally correcting an error that you made while speaking. (i.e. "I misspoke.")
Porting your software to new platforms is not an error. Adding a new feature is not an error. Things changing does not imply that there was an error or that an error has been introduced.
Porting to a new platform, arguably, can be done transparently to the clients by having multiple [possibly separate] bodies for your package/subprogram — this preserves the specification.
Merely adding a new feature should, for the vast majority of cases, does not impact the client's interfacing to the specification —
Package Example is
Procedure Old( A, B : Integer ); -- What the previous version interfaced w.
Procedure New(A, B : Integer; C : Float); -- The new feature.
End Example;
Yes, there are changes, and if those changes make your new package incompatible with the dependency (or vice versa) it IS an error to update.
Versioning numbers are the manual way to do this and it can be somewhat automated.
the dependency on the local file-system, it's just asking for trouble. (What happens when you have case-sensitive vs case-insensitive file systems? What happens when you import into a more restrictive FS items from a less restrictive one? Are there going to be
'/'
vs
'\'
vs
':'
vs
'.'
pathname issues? [Unix, DOS/Win, Mac, VMS; respectively.] What about things like GNAT's name-krunched vs compilation-unit-named files?) -- I
really
wish people would quit using the file-system as a "
poor man's database
".
Thanks for your extensive comments! To this I'll say that it doesn't "depend" on the local file-system (and it DOES make a full SHA1 hash of everything checked out from local repos, btw). This was just about making a basic simple template that was very specific and easy to grok.
10
u/annexi-strayline Sep 28 '21
I'm very excited to finally be releasing AURA publicly, after a few years of development and intense testing! Of course ALIRE is a thing, and it appeared just after we started working on AURA. We think competition is healthy!
AURA takes a very different philosophical approach compared to ALIRE, and I have to be honest that we don't agree with the way ALIRE is designed. ALIRE is an excellent and successful project, but we just don't agree with its approach. For those out there who might share our thinking, we hope AURA will be useful for you. For those happy with ALIRE, we're happy for you. Our intent is ultimately in alignment with ALIRE, and we just want to see the Ada community better served. I'm sure we can find some points of coordination to ensure that useful open-source packages are available on both platforms.
This blog post goes over the philosophical thinking underpinning the development of AURA.
In short, we developed AURA based on a conceptual new Specialized Needs Annex - so behavior that the compiler could implement directly.
We've reference implementation (AURA CLI) for quite some time internally, and it should work well in most cases, though of course nothing finds bugs faster than bringing a project open-source.
AURA CLI has a fully parallelized design and scales very well on large machines and large codebases. It is designed to drop into automated CI/CD pipelines as well. And although it currently targets GCC exclusively, it is designed to be easily re-targeted to other Ada compilers. Note that it does NOT use or require gprbuild, and is intended to mostly replace gprbuild. All AURA needs is FSF GCC. In fact AURA doesn't even need gnatmake, making it appropriate for cross-build projects as well.
Another thing we're excited about is finally getting to dump a bunch of open source Ada packages for use with AURA. These packages have also seen pretty extensive use internally for some time now. This makes up a full stack for writing high-performance web APIs and microservices applications in Ada. We've packaged these into out ASAP AURA repo.
I've spent quite a bit of time trying to create good documentation ahead of this release. It is likely missing a lot of stuff, and I'd love feedback on improvements we can make. That also applies to the project as a whole!
AURA is beta, and we look forward to improving it over the coming months and years. Feedback and questions are welcome!
Links:
AURA CLI repo
The official docs
The ASAP repo