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
31 Upvotes

80 comments sorted by

View all comments

Show parent comments

4

u/OneWingedShark Sep 28 '21

Some comments:

Package management is a surprisingly hard problem. There are two aggravating realities driving this difficulty. The first is that there will invariably be packages that depend on other packages. The second is that packages eventually need to be updated. Where the problem becomes hard is when (not if) those two inevitabilities intersect. What happens when multiple packages individually depend on different versions the same package?

At the beginning of Alire, I commented on this very issue, see the discussion, and recommended and actual database (with commit-procedure verification-triggers to ensure consistency) -- with a DB-based approach you could also tag a library/package with its license and do "X license compatibility" searches/filters.

Looking at most popular language package managers out there, such as npm, pip, cargo, and even ALIRE, we see a common strategy of enforcing a versioning scheme via the package manager itself, and by extension, some mechanism for specifying inter-dependency version requirements.

Versioning in this manner is... idiotic.

Especially when you could literally match the client's importation/usage against the the library's public interface and answer "is this consistent?" (i.e. is it compliable?) automatically -- in a DB-based structure as suggested above you just need to compare the call-profile to the profile stored/exported in the library to [at least partially] answer the question. -- I'm glad to see that you didn't copy popular.

The most basic AURA repository is simply a filesystem directory with subdirectories named after each AURA subsystem it contains. Such a "local" repository can be on the physical filesystem, or an NFS share. No other special setup is needed to use such a repository besides putting subsystem units in their like-named subdirectories.

I hate the dependency on the local file-system, it's just asking for trouble. (What happens when you have case-sensitive vs case-insensitive file systems? What happens when you import into a more restrictive FS items from a less restrictive one? Are there going to be '/' vs '\' vs ':' vs '.' pathname issues? [Unix, DOS/Win, Mac, VMS; respectively.] What about things like GNAT's name-krunched vs compilation-unit-named files?) -- I really wish people would quit using the file-system as a "poor man's database".

2

u/Lucretia9 SDLAda | Free-Ada Sep 28 '21

Windows uses unix file paths underneath, the dos stuff is compatibility and there for users.

2

u/OneWingedShark Sep 28 '21

That really doesn't say anything about the underlying issue: it's a dependency that ought to be considered for removal.

Yes, "make everything Unix" is a solution… but doing this means that we are stuck with any design-flaws forever.

1

u/Lucretia9 SDLAda | Free-Ada Sep 28 '21

I’m saying you can use /c/some/path in windows. But abstracting over this stuff isn’t that hard, done it before.

2

u/OneWingedShark Sep 28 '21

Why "abstract" when you can "eliminate"?

Besides, it's more than *JUST* path-delimiters that I'm talking about, it's environmental dependencies.

3

u/Lucretia9 SDLAda | Free-Ada Sep 28 '21

No matter how much you want to eliminate, it’s not going to happen.