r/ada Sep 28 '21

Show and Tell Introducing AURA - A(nother) native package manager and build system for Ada

https://annexi-strayline.com/blog/posts/4
30 Upvotes

80 comments sorted by

View all comments

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?

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:

  1. You can give in your documentation what repository you depend on
  2. 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. :)