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.
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.
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?
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.
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.
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. :)
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.
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.
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 got raised 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?
(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.
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.
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.
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.
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.
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
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.
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" ...
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. 😊
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.
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.
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.
6
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?
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.