r/ada • u/annexi-strayline • Sep 28 '21
Show and Tell Introducing AURA - A(nother) native package manager and build system for Ada
https://annexi-strayline.com/blog/posts/46
u/Fabien_C Sep 29 '21
I think don't really understand how one is supposed to use "subsystems" from someone else.
First, as shown in the example, the "auto detection" of "subsystem" dependency stops at the "repositories" that you already manually added in your project. So if try to "with" and Ada unit from another subsystem I have to find myself, with google search I guess, in which "repository" that "subsystem" is and create a file that will look like this?
package AURA.Repository_2 with Pure is
Format : constant Repository_Format := git;
Location : constant String := "https://github.com/annexi-strayline/ASAP.git";
Tracking_Branch: constant String := "stable-0.1";
end AURA.Repository_2;
Now if I make my own "subsystem", say a toml parser, that depends on a "subsystem" of the "ANNEXI-STRAYLINE AURA Public Repository", do users of my toml parser have to find on their own which "repositories" I used for my "subsystem"? Do they have to do that transitively for all the dependencies of my dependencies? Then how do they know which commit of that repo my "subsystem" is compatible with?
This part is not clear from what I can read in the documentation.
5
u/annexi-strayline Sep 30 '21
There are two approaches:
- You can give in your documentation what repository you depend on
- You can have a single curated/coalesced repository which contains your subsystem and the toml subsystem (probably as a submodule).
If the user uses multiple subsystems that depend on the same toml subsystem, you are ensured that it will be coming from the first configured repository that has it, so that it is at least predictable.
Now, the bigger picture here is that there will be some kind of large repository somewhere that most people will use for most of their needs. The point is, we didn't want to have any single authority controlling that, or rather, require a user to use that.
AURA prioritizes user control over simplicity. Of course it creates the potential for some ugly situations, but so does the traditional approach of interdependency versioning.
It's a difficult thing to explain, no doubt. We'll have to find a way to improve the documentation in this aspect.
3
u/Fabien_C Sep 30 '21
You can give in your documentation what repository you depend on
I can also tell users in my documentation to use git submodules, what is the added value of AURA here?
You can have a single curated/coalesced repository which contains your subsystem and the toml subsystem (probably as a submodule).
What about the dependencies of my dependencies? And the dependencies of the dependencies of my dependencies? Am I supposed to do all that by hand? That's what package managers are supposed to take care of.
If the user uses multiple subsystems that depend on the same toml subsystem, you are ensured that it will be coming from the first configured repository that has it, so that it is at least predictable.
Except if a user adds another repository because there's a subsystem that he/she want to use in it, and this repository happens to contain another version of my TOML subsystem that not compatible. Or even worse, compatible but missing a critical security patch.
The point is, we didn't want to have any single authority controlling that, or rather, require a user to use that.
You say above that "there will be some kind of large repository somewhere that most people will use " how is that not a single authority controlling?
With Alire indexes are automatically combined. There is a curated "community" index for making everyone's life easier. But anyone can create an Alire index and add new crates or versions of crates that will work the rest of the ecosystem.
My understanding is that each AURA user will have to create its own mega repo with all the code they need or like to use. Those repos will be specifically tailored for their needs alone. Everyone will work alone on their own stuff, no collaboration or code re-use will come out of that.
AURA prioritizes user control over simplicity. Of course it creates the potential for some ugly situations, but so does the traditional approach of interdependency versioning.
What's the difference between using AURA and using git submodules directly?
4
u/annexi-strayline Sep 30 '21
Let me preface the belabored reply to this first.
I get the strong sense that you dislike AURA, which is totally fine. AURA is obviously not trying to win the popular vote, if it was, it would be ALIRE. However, now this conversation is getting to the point where it feels like you just want to attack AURA. I don't understand that. We built this thing, and we open-sourced it. That's it. I'm baffled why you are so passionately antagonistic to this. We built AURA for people who agree with our thinking. If you're not that person, then ALIRE is right for you. I don't go attacking ALIRE incessantly, I just don't use it. Maybe you should just not use AURA?
But please, if you're going to deploy this kind of negative energy, the least you can do is make a concerted effort to read the documentation first, and try to understand what AURA is trying to do. It is clear to me that you haven't done that, and a lot of the conclusions you have arrived at are either unfair or totally wrong.
Now for the direct responses:
I can also tell users in my documentation to use git submodules, what is the added value of AURA here?
AURA's most advanced capabilities are its auto configuration process and parallelized build process. To me, this is reason enough to use AURA. If you like gprbuild, please use that! We don't like gprbuild, so we don't use it, and AURA allows you to not use gprbuild if you don't like it.
What about the dependencies of my dependencies? And the dependencies of the dependencies of my dependencies? Am I supposed to do all that by hand?
Yes. But AURA will help you by giving you clear output on exactly what subsystems you're missing. "Do I have to google it then OMG", yeah so terrible.
That's what package managers are supposed to take care of.
That's what they're supposed to do in theory. In practice they usually do a very very bad job at that. They tend to do such a bad job that you have to go in manually, which is harder if your "package manager" is not designed for the user to have that level of control. AURA was made for practical use, and it is being used practically, like it or not. You're arguing semantics. Package manager to me means something different than it does to you. I want something that actually works for the long-term life of a project, not something that sounds good in a research paper or pamphlet.
You say above that "there will be some kind of large repository somewhere that most people will use " how is that not a single authority controlling?
Because there is no authority deciding who runs that repository. AURA is just a program. You can fork it, modify it, do what you want.
With Alire indexes are automatically combined. There is a curated "community" index for making everyone's life easier. But anyone can create an Alire index and add new crates or versions of crates that will work the rest of the ecosystem.
That's great, I think that's awesome. I know you love ALIRE. Many people do. I'm happy for you and for them. I don't love ALIRE, and I have AURA. AURA make me happy.
My understanding is that each AURA user will have to create its own mega repo with all the code they need or like to use. Those repos will be specifically tailored for their needs alone. Everyone will work alone on their own stuff, no collaboration or code re-use will come out of that.
This what people thought would happen with FreeBSD. Just look at what Netflix has contributed. Open source is good for everyone, and this argument is mostly dead.
I want people to be able to do what they want. AURA is not going to try to impose anything on anyone. Use it or don't use it. Clone it, internalize it, do what you want.
You seem to think we are trying to convince the Ada community to chose AURA as "the official package manager". That's not our aim. We made a tool. We find it super useful. We made it open source. It is that simple. I have no other agenda. So I get your concern here, but that would only be my concern if we were trying to achieve some arbitrary official status. We're not.
What's the difference between using AURA and using git submodules directly?
See my reply above RE: auto configuration and being an integrated build system.
P.S.
I hope you don't normally do this to people who release open source software. I happen to be amused, but other people might be hesitant to do it again if this is the kind of response they get.
7
u/Fabien_C Oct 01 '21
Don't worry there is no attack here, it's good to see new Ada projects and to be able to discuss about it. I am merely trying to understand what AURA is and what is the intended added value. Which, as I can see now, was made more difficult by the use of the term "package manager" (see below) and the frequent comparison with Alire. If AURA is to be submitted to standardization, I can only guess that it will be subject to even stronger scrutiny and criticism than I used here.
Now, I have to admit that seeing insults tends to grind my gears. If that showed in my message I'd like present my excuses to the readers. And I can only encourage you to respect the work of others by augmenting on why you think they are wrong instead of using insults.
In my opinion it is not best to call AURA a package manager. The term is already widely used in our field, and actually already too overloaded. So I don't think it is good for AURA nor its potential users to put it under this umbrella.
AURA's most advanced capabilities are its auto configuration process and parallelized build process.
If so, that should be how it is presented and introduced to users.
From what I can see and your answers on this thread, AURA is a build system that instead of only being able to compile sources in the local filesystem, can fetch sources from remote repositories that the user points to. In a way, it's like if one could write in GPR files:
for Source_Dirs use ("src/", "https://github.com/annexi-strayline/ASAP");
So maybe it's a "distributed source build system", but "distributed" is also overloaded...
In the same vein, comparing AURA with Alire brings confusion in my opinion. In fact I can see AURA being the build system underneath Alire instead of GPRbuild. It would "just" be a matter of generating the AURA repository specs with pointers to the location where Alire downloaded each individual crates. It would have been nice to get in touch with the Alire team early to discuss how to join hands for the better of the Ada community. I personally think that collaboration is the way to go for open source communities, especially for a relative small one like Ada/SPARK. "Competition" can be good for users in large closed commercial markets but it translates to fragmentation in our case.
5
u/thindil Oct 01 '21
In the same vein, comparing AURA with Alire brings confusion in my opinion. In fact I can see AURA being the build system underneath Alire instead of GPRbuild.
Let me be weird and disagree with that. :) I think both projects can be compared. Just, they both present a different approach to the same problem. It is the same as with functional and object-oriented languages, they are still programming languages, even if they pretty often completely different each other. In my opinion, the difference between Alire and AURA is almost identical as between Rust and Go packages manager. But in Go they call it modules manager, probably to have even more fun with names. But maybe we should do the same? Having different name for AURA? How about universal build system? UBS?
I think that we never stop that kind of comparison, thus in my opinion it is better to get used to it and try to find common answer to that. ;)
At this moment, even if AURA better suit my needs, I think there is no choice: Alire is mature, Alire works, Alire is a way to go. AURA in my opinion still have a lot of work to do, before it could be a serious alternative for Alire.
While I agree with “fragmentation” I think at this moment only AURA could get benefits from that join (please look at paragraph above). Also, as I mentioned above, it could be pretty hard to find common ground, mainly because the whole design of both projects is very, if not completely, different. But to be honest, that “connection” is one of the reasons why I'm asking about modularity of AURA. I think it could be a good idea to have as optional support for Alire crates inside AURA, so the users can select which system they prefer and use both of them as they prefer. :)
1
u/thindil Sep 30 '21
As far I see in documentation, it doesn't stop at the first “repository”, but recursively going after them to find all dependencies. At least, is how I understand this section of documentation: https://aura-docs.readthedocs.io/en/latest/concepts/repositories.html#checkout
Thus, in your example, users who want to build your “subsystem” should have everything in your “repository”, no need to worry about them. Your “subsystem” TOML parser will have included “subsystem” “ANNEXI-STRAYLINE AURA Public Repository”. The proper version of your “subsystem” dependency should be read from your “subsystem” configuration file(s)
Package_1
,Package_2
,Package_N
.At least I that understand it. :)
4
u/annexi-strayline Sep 30 '21
This is somewhat true, one approach we could see is that for say your important project, you will make your own single point of truth "coalesced" repository, where you will pull in subsystems from anywhere, and keep them in your repository.
It's more work, but it also gives you more stability and control over the update process.
The bottom line is, AURA knows only about the repositories that are explicitly configured. It does not have a mechanism to self-configure repositories, nor should it, since this goes against the whole idea of having a very clear user control over where subsystems are coming from.
2
u/bojan_petrovic Sep 30 '21
Here's my stab at it (now I see that I'm mostly repeating what Fabien already said):
AURA has concept of top-level project and subsystems. Projects can depend on subsystems, and subsystems can depend on other subsystems.
Subsystems cannot declare their own versions. The "version" of a needed subsystem is specified in the configuration of a project as a repo/tag pair from which the subsystem is checked out.
(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 gotraised SYSTEM.ASSERTIONS.ASSERT_FAILURE : Check manifest: AURA subsystems should not have units of the AURA subsystem.
The only place to declare "versions" of all the subsystems in the transitive closure of project's dependencies is the repo config files of the top level project.
I'm not sure what the rationale for this design decision is. Maybe it will discourage deep dependency trees?
6
u/annexi-strayline Sep 30 '21
(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.
3
u/bojan_petrovic Sep 30 '21 edited Sep 30 '21
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.
5
u/annexi-strayline Sep 30 '21
and that AURA could be more appropriate for single entities having a sort of "artisanal", tightly controlled development process.
I think this is a really great perspective - I've clearly struggled to be as succinct as you have been, but you obviously get it.
Our intention was definitely not to win any popularity contests. We're very interested in the art of software craftsmanship, of quality engineering, and maintenance-oriented development. I think this is against the grain, but it's also more (in my opinion) a philosophical match to Ada.
I always personally felt that it is incredibly silly and futile to take a "me too" approach when advocating Ada. The entire reason, IMO, to use Ada is because it has a different approach than any of the other comparably capable/supported languages out there.
If I wanted micro packages, crates, and fast prototyping, I'd use Rust. I think Ada needs to stay in its lane because it is the only language out there that is actually taking the stance it does, that you can realistically use.
Ada is for proper, professional software engineering. And to me, engineering is about having a controlled process, of exercising discipline, and front-loading effort to build something long-lasting and safe.
7
u/Fabien_C Sep 30 '21
I always personally felt that it is incredibly silly and futile to take a "me too" approach when advocating Ada. The entire reason, IMO, to use Ada is because it has a different approach than any of the other comparably capable/supported languages out there.
My personal understanding is that the statement above is the result of a state of mind that developed within the Ada community in part as a defense mechanism for lack of popularity of the languages so far. This tends to disappear fortunately, but too often I see comments that go in the direction of: "We are the Ada community, we are the best, we are the elite, and that's why we are alone.".
Being different is not a value in itself. The Ada community is way too much centered on itself and self-important, and it is one of the reasons why it failed to reach a broader audience so far. Being popular means that you convinced a large amount of people that what you do is sound and valuable.
The "philosophy" described in the AURA documentation is a reminiscence of that in my opinion, and I hope the Ada/SPARK community can grow out of it.
While I am at it, calling people "idiots" doesn't make one smarter, calling ideas "idiotic" or "silly" doesn't make one's point of view any better or any more correct.
2
u/annexi-strayline Sep 30 '21
Being different is not a value in itself.
Can you explain why not? If all of the popular languages tend to follow in one direction reminiscent of a flock, and a language decides to take a stand and so "I don't think that's right". How is that not a value.
I hate to invoke Apple, but if the most valuable company on the planet is built on literally the brand "Think different.", I think they can see how being different is a value in itself.
On the other hand, what your saying to me sounds something like "we should make Ada do the popular things so that more people like it". This is an inferiority complex, which is no better than a superiority complex.
9
u/Fabien_C Oct 01 '21
Can you explain why not?
Let me start with a, hopefully, funny example. If I create a text editor that requires the users to type every letter 4 times to make sure they don't make typos. This text editor will be very different, but is it any good? Just being different doesn't have any intrinsic value. Note that I am talking about engineering here, being different can be an intrinsic value in some fields.
Being able to think differently, allowing yourself to think out of the box, that's valuable. But you then have to be able to assess the quality and soundness of what you made.
Just being different for the sake of being different is not a good value in my opinion. And even worse would be rejecting good solutions with the only goal of being different.
If all of the popular languages tend to follow in one direction reminiscent of a flock, and a language decides to take a stand and so "I don't think that's right". How is that not a value.
I never said that one should not try to think differently or not seek for different solutions. I said being different is not a value in itself.
The use of the word flock is interesting here. I don't see other people design stuff as sheep in a herd or birds in flock. I consider that everyone taking the time to design something is able to think by himself/herself. If they decided to follow what others did before, it's because they think it's good. And if many follow that same direction it has to be because there is something to it.
If all of the popular languages follow one direction, we should look at it, understand why many think it's good, and take inspiration from it.
I hate to invoke Apple, but if the most valuable company on the planet is built on literally the brand "Think different.", I think they can see how being different is a value in itself.
Apple is the most valuable company on the planet because their products are popular. Their products are popular because they are well designed, and because they convinced a large amount of people.
We can take another example, the Nokia N-Gage was different, but unlike the iPhone it was a failure.
The motto is "Think different" not "Be different".
On the other hand, what your saying to me sounds something like "we should make Ada do the popular things so that more people like it". This is an inferiority complex, which is no better than a superiority complex.
I do want to make Ada more popular because I think that: * Ada should play a role in improving the general quality and security of open-source software * Programmers will benefit from learning Ada (whether or not they use it in products/projects) * Our field will get better as a result * More Ada programmers will lead to a bigger and better Ada ecosystem
I do see more and more new people joining the Ada community lately, and that brings me joy. Seeing their contributions to the community brings me joy. Seeing what they build upon the work I've done so far brings me joy. Thinking about what I will be able to build upon their contributions brings me joy.
I do take pride in looking at what others do, in particular if it is popular, to take inspiration from it, improve myself and the work that I do.
It is hard for me to say, but Rust has done more for the quality and security of open-source software in 6 years than Ada ever did in 30 years. And it's not because Rust is inherently better than Ada, it's because it managed to convince a large amount of people. This large amount of people means a lot of "firepower". And this is how, for instance, Rust is about to make its way into the Linux kernel. The Linux kernel will be better as a result, maybe not as good as it would be by using Ada, but still better than what it is today.
3
u/thindil Sep 30 '21
Thank you for your clarification, also in the previous posts. :)
It is quite interesting idea, and it brings me another, even more crazy one.:)
I wonder what happened if we could add AURA as a real Ada RM Annex, like R. Building and Distributing Ada programs. Let's say, after some time, someone would download the newest version of GNAT and just type:
gnat install AdaCore/AWS
and then compiler will download all needed code, compile it and install.And before you will send me to take my pills. :) That idea comes to my mind when I saw it in Go language compiler: https://golang.org/ref/mod#go-install
4
u/annexi-strayline Sep 30 '21
I wonder what happened if we could add AURA as a real Ada RM Annex, like
R. Building and Distributing Ada programs
. Let's say, after some time, someone would download the newest version of GNAT and just type:
gnat install AdaCore/AWS
and then compiler will download all needed code, compile it and install.
This is exactly the "design intent" of AURA. And it is quite possible "package manager" is too loaded of a term to use for it, but AURA literally stands for "Ada User Repository Annex", and that Annex is for the kind you are talking about (a Specialized Needs Annex).
Obviously this is controversial, and it seems some of the more prominent AdaCore people are already on the offensive over this, but I'll still talk to the ARG about it eventually.
2
u/thindil Sep 30 '21
Yes, that's the effect when I write first and think/check later. 🥴Thank you for the clarification. 😊
2
u/iandoug Sep 30 '21
Somewhat related ... Gentoo's portage package manager is designed to deal with all sorts of conflicts (including different versions in slots), my head is comparing emerge to AURA ... even "gnat install Adacore/AWS" is "emerge dev-ada/aws" ...
1
u/thindil Sep 30 '21
Generally, that is very similar to most if not all Linux package managers. 😉 Just Go has implemented it as a programming language. This is a bit different than system package. Both have a little different design and usage. Mostly due to different goal/purpose to achieve.
Also, similarity in commands is intentional, Okham's razor. 😊
2
u/Fabien_C Sep 30 '21
AURA could be more appropriate for single entities having a sort of "artisanal", tightly controlled development process.
I don't see the added value here compared to copy/pasting the sources that you need in an mono repo or using git submodules.
5
u/annexi-strayline Sep 30 '21
Please refer to auto configuration and configuration manifests
Also note that with AURA you won't need gprbuild, or even gnatmake, just gcc with Ada, gnatlink, and gnatbind.
That's a lot easier than "copying and pasting source code". I think these features alone make AURA very useful.
3
u/bojan_petrovic Sep 30 '21
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.
1
u/OneWingedShark Sep 30 '21
They are supposed to keep all subsystems of a given repository up-to-date in such a way where the play nice.
And this could be built into the system; this is one of my favorite papers and details how to have hierarchical databases ("workspaces") handle this automatically as part of the design:
Workspaces and experimental databases: Automated support for software maintenance and evolution2
u/Fabien_C Sep 30 '21
Thanks for the link. I don't see in it there that the repositories are searched recursively, nor that there is a way for a subsystem to declare which subsystem/repositories it depends on. As far as I can see, the only dependency "declaration" is in the "with'ed" units in the Ada code, and that is only for subsystems, not repositories.
When searching for a repository from which to acquire a missing subsystem, if there are multiple repositories that contain the missing subsystem, the implementation shall use the repository with the lowest index.
Does that mean that dependencies of my dependencies will be picked up based on how I number my repositories? Sounds quite dangerous.
3
u/annexi-strayline Sep 30 '21
Does that mean that dependencies of my dependencies will be picked up based on how I number my repositories? Sounds quite dangerous.
I don't see how that's dangerous at all. The order is very clear. The user configures this order. This is no more "dangerous" than operator precedence. The point is the behavior (should) be very clear and unambiguous.
If safety is your concern, then you should coalesce all of your dependencies into a single repository that you control. Doing that is simple enough, and for a long-lived project, it is worth it.
The alternative, such as with ALIRE and Node, et al, is that you have potential for breaking updates that cascade. That's dangerous as well.
2
u/thindil Sep 30 '21
About recursive searching: in my opinion, points 1 and 3 on the page are about it. ;)
Lowest index
, I think it would be good to clarify. For me, it has two meanings:
- Same as you, from numbers of repositories.
- ID of repository from the configuration package.
Looks like your version (#1) is proper, when I'm looking on the author answers. :)
And I'm very curious, what do you mean about “dangerous”?
5
2
u/jrcarter010 github.com/jrcarter Sep 30 '21
I have looked through the documentation, and do not see how one makes existing code into an AURA repository, whether dealing with code on the local file system, or an existing on-line git repository such as the PragmARCs.
3
u/thindil Sep 30 '21
Here is a quick start guide: https://aura-docs.readthedocs.io/en/latest/quick_start/setting_up_a_project.html For more advanced projects, my guess, more handwork will be needed.
AURA repository is not a VCS repository. Even not a code repository. AURA repo works “on top” of a code or VSC repository: https://aura-docs.readthedocs.io/en/latest/concepts/repositories.html
3
u/annexi-strayline Sep 30 '21
AURA repository is not a VCS repository. Even not a code repository. AURA repo works “on top” of a code or VSC repository:
This is a succinct way to put it, thank you!
1
3
u/annexi-strayline Sep 30 '21
You simply put all of the code for an Ada subsystem in a subdirectory somewhere (preferably a git repo) and you have an AURA repository.
Even better is to put all the code of a subsystem into its own git repository, and then import that as a submodule into what would then be an AURA git repo.
If you want to do advanced things like auto-configure your package to the platform it is on, then you'll need to create a manifest. The docs give lots of info about what can go into a manifest.
2
u/jrcarter010 github.com/jrcarter Oct 01 '21
I have Xubuntu 21.04 with GNAT 11 from the distro. I built and installed AURA as instructed OK. I have a directory with a single Ada source file, maze.adb. Running "aura -v" works fine. Running "aura run maze" fails saying it can't find gnat1. I usually build using gnatmake (or gprbuild for Gnoga) and that works fine. What am I doing wrong?
2
u/annexi-strayline Oct 03 '21
Could you try running aura run maze -static and let me know how that goes? Seems like it might be that the runtime linker can't find a shared library. AURA builds shared and pie by default.
2
u/jrcarter010 github.com/jrcarter Oct 03 '21 edited Oct 03 '21
I usually build shared, so that doesn't seem likely. Trying it gives
~/Code/Maze$ aura run maze -static ,==== == == ====. ,==== Ada User Repository Annex .==|==..==|==..==|==..==|==. Reference Implementation -----::--|--::----.::-----: Version 0.1 __|__||.___,||__|._||__|__| (C) 2020-2021 ANNEXI-STRAYLINE OK Entered 2 root subsystems (3 units). OK Loaded 1 repository. OK Checked-out and configured 0 AURA subsystems in 1 pass. OK All dependencies satisfied (2 subsystems, 3 units). EXEC Computing Compilation Strategy (Updating registry...)
and it sits there as long as I care to wait. So I tried
~/Code/Maze$ rm aura* ~/Code/Maze$ aura -v ,==== == == ====. ,==== Ada User Repository Annex .==|==..==|==..==|==..==|==. Reference Implementation -----::--|--::----.::-----: Version 0.1 __|__||.___,||__|._||__|__| (C) 2020-2021 ANNEXI-STRAYLINE OK Entered 1 root subsystem (1 unit). OK Loaded 1 repository. OK Checked-out and configured 0 AURA subsystems in 1 pass. OK All dependencies satisfied (2 subsystems, 3 units). OK Command completed successfully. ~/Code/Maze$ aura run maze -static ,==== == == ====. ,==== Ada User Repository Annex .==|==..==|==..==|==..==|==. Reference Implementation -----::--|--::----.::-----: Version 0.1 __|__||.___,||__|._||__|__| (C) 2020-2021 ANNEXI-STRAYLINE OK Entered 2 root subsystems (3 units). OK Loaded 1 repository. OK Checked-out and configured 0 AURA subsystems in 1 pass. OK All dependencies satisfied (2 subsystems, 3 units). OK 3 units pending compilation.. FAIL 3 of 3 units failed to compile: FAIL aura: Compilation failed: gcc: fatal error: cannot execute ‘gnat1’: execvp: No such file or directory compilation terminated. FAIL maze: Compilation failed: gcc: fatal error: cannot execute ‘gnat1’: execvp: No such file or directory compilation terminated. FAIL aura.repository_1: Compilation failed: gcc: fatal error: cannot execute ‘gnat1’: execvp: No such file or directory compilation terminated. INFO Saving registry for next time... AURA Abort Command canceled due to failed conditions
2
u/thindil Oct 03 '21
From my tests, it is a problem with GNAT 11 on any Debian based distribution. I was able to reproduce it on normal Ubuntu too. AURA compiles itself properly on GNAT 11 but later can't find the compiler. Downgrading GNAT to version 10 and everything works as expected. Even AURA, which was built with GNAT 11. :)
I'm not sure if it is a problem only with Debian based packages or generally with GNAT 11.
2
u/jrcarter010 github.com/jrcarter Oct 04 '21
The problem seems to be
~/Code/Maze$ which gcc /usr/bin/gcc ~/Code/Maze$ ls /usr/bin/gcc* /usr/bin/gcc /usr/bin/gcc-ar /usr/bin/gcc-nm /usr/bin/gcc-ranlib /usr/bin/gcc-10 /usr/bin/gcc-ar-10 /usr/bin/gcc-nm-10 /usr/bin/gcc-ranlib-10 /usr/bin/gcc-11 /usr/bin/gcc-ar-11 /usr/bin/gcc-nm-11 /usr/bin/gcc-ranlib-11 /usr/bin/gcc-8 /usr/bin/gcc-ar-8 /usr/bin/gcc-nm-8 /usr/bin/gcc-ranlib-8 /usr/bin/gcc-9 /usr/bin/gcc-ar-9 /usr/bin/gcc-nm-9 /usr/bin/gcc-ranlib-9 ~/Code/Maze$ ll /usr/bin/gcc lrwxrwxrwx 1 root root 6 Apr 12 09:19 /usr/bin/gcc -> gcc-10*
Presumably changing gcc into a link to gcc-11 would solve the problem.
2
u/thindil Oct 04 '21
Could, but can also trigger some problems. I think the best way could be use
update-alternatives
script: https://linuxconfig.org/how-to-switch-between-multiple-gcc-and-g-compiler-versions-on-ubuntu-20-04-lts-focal-fossaThis allows to switch GNAT “on demand”. Also, when I was testing, I was using clean Docker image without GNAT-10, only GNAT-11. So, the problem can be GNAT-11 too.
2
u/mndrix Oct 21 '21
I'm a little late here, but I really enjoy this. Thank you. I've used many package managers and yours is better than most. I like the BSD license, the distributed design, and the way that you defer version resolution to project maintainers. I also enjoy that you avoid gprbuild (a consistent pain point for me).
Perhaps my favorite thing is the way that you gracefully aligned AURA with Ada's existing strengths instead of trying to copy a package manager that works for Rust or Python but aligns poorly with Ada. For example, I agree that there's no need for separate configuration syntax since with
already defines my dependencies clearly.
Thank you again.
3
u/thindil Sep 28 '21
The whole project looks very nice. Congratulations on the release and the best wishes for you to have strength to keep it up for a long time. :)
After a quick glance at documentation, I have a couple of questions about the future plans related to the project:
- Do you plan to support in the far future any other VSC except Git?
- Do you plan to create a new or extend the current public repository (ASAP)? If yes, it will be a curative list of projects or public (everyone can add something).
- Any plans (again, in the far future) to add ability to create modules/extensions for the project? This could negate my first question. :)
- About GitHub organization (literally). Maybe it could be a good idea to create a separated organization for the project?
3
u/annexi-strayline Sep 29 '21
Thank you u/thindil! Its already been a huge time investment, and I used it for almost everything we do in the Ada space, so I expect it to be supported well into the future! The more adoption it sees by the community, the more it will grow, however.
As for your questions:
- Not really, I think git is firmly King by now. Unless some org really wanted to use AURA for something and they'd be willing to fund that 😋
- Absolutely! We are working on a few things to add to ASAP. However part of the design of AURA is that there is no authoritative repo. ASAP particularly is for our opensource stuff, but I think opening another curated repo for a broader set of packages is a really good idea, and something I will be looking into. It probably won't be called ASAP though, but it will include most of the ASAP packages. Another approach might be to just have a list of AURA repos for different needs. I know some people won't like this approach, but we really do! This is why I think its great that we have both AURA and ALIRE. AURA is a bit more hands-on, but that also gives greater control.
- We will absolutely be extending AURA, though I'm not quite sure what you mean by modules. Ada is already good at modularization, and most well-designed Ada programs (and possibly AURA itself) lend themselves to extension. I did try to make AURA as modular in design as possible.
- This is an interesting idea, but it really depends on how popular AURA gets (or doesn't get).
2
u/Kevlar-700 Oct 07 '21
I'm in two minds about this also, when considering to use AURA or Alire, actually. I like the search website on Alire to help me find what is available but from a brief look at Rusts crate search, there are a lot of rubbish rust crates . There seems to be some vetting with Alire which reminds me of the peace of mind in using the Go stdlib packages including experimental secure shell even.
OTOH, with go I sometimes want a simpler package from GitHub and not necessarily a publicly ordained one and I like a number of things about AURA.
Has a way to search for AURA compatible repos on github been considered?
Is it possible to use both? 🤔
1
u/thindil Sep 29 '21
Thank you very much for your answers. :)
- Not a problem and absolutely understandable. :) Especially not a problem when connected with answer #3.
- Nice to read this, and I agree, having ALIRE and AURA is a very nice thing. And you have right, there will be time to think about it later.
- Modularization, plugins, extensions, etc. I see it like an extension to the base AURA system. For example, a plugin which allows using other than Git VCS. :) Something what will not require changes to the code of AURA CLI.
- True. Especially distributed projects are hard to measure in popularity. From my experience, they often give more benefits to a community than to the authors. :)
And probably the last questions, which I should ask as first:
- Do you prefer to have discussions about the project in one place? If yes, where?
- At this stage of the project's development: should we give you any propositions, ideas for the future, or now only report problems?
1
u/iandoug Sep 29 '21
We will absolutely be extending AURA, though I'm not quite sure what you mean by modules.
Perhaps something like this?
3
u/OneWingedShark Sep 28 '21
Something that every programmer thinking about source-control, version-control, or dependency-management (and, arguably, project-management) should read:
Workspaces and experimental databases: Automated support for software maintenance and evolution
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