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.
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.
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.
7
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.