New, BIG, Tada release!
It supports “tada install” using a global package index and an included testing framework!
2 Likes
What are your goals with Tada? How does it compare with Alire or Aura? Will there be commands to install libraries and executables for local use?
Tada is a project for personal use. I know Alire exists, is more feature rich and has hundreds of packages. And that’s fine. Tada is something I always wanted to build. I write Ada for fun and decided to build many projects in it to understand how the foundational pieces work under the hood. I plan to release more projects in Ada in the near future, and I want to create my own little programming world around the language. I hope someone finds it useful.
There istada install . WDYM by “local use”?
Alire, and other package managers, have commands that install executables or libraries to somewhere they can be used easily. Usually it’s called something like “install”. I thought the install command in Tada was a way to tell Tada that the current project depends on a particular package. Was I mistaken? And if so, how do you tell tada one project depends on another?
In any case, I encourage you to continue developing Tada; just the learning you do will be very valuable, and I also thing having another approach at a package manager is good for the ecosystem in general.
1 Like
tada install copies the dependency from the index to ~/.cache/tada/package/NAME/VERSION on Linux / MacOS or to %"LOCALAPPDATA%\tada\package\NAME\VERSION on Windows.
There was a tada cache command doing exactly what you said. Now, I’m thinking, it would be worth to bring it back, as it would be easier to develop locally without using the index. Thanks!
Alire is a crate system, not a package manager.
I would say that a package manager installs into a predefined defined location, because for a complex software system it might be impossible to move installation around. So fake root and other tricks go.
Crate system users will face this problem too when start to use interdependent projects. They will discover necessity to remap the directory structure in order to make all project files and executables working and be able to test and debug the whole bundle of packages. For example bin/, lib/, fonts/, etc/ and so on directories.
Done! 
I know “crate” exists as a word, but for me it’s Rust-centric
I would differentiate system-level from language-level packages (and yes, call both of them packages) and be pragmatic. Or: it’s a pragmatic choice for me / it works for me.
Sure, but was it possible to connect different libraries? My (perhaps wrong) impression with DEC Ada and ObjectAda was/is there was/is one library per project but you could/can not see/“with”/use library Y from library X.
GNAT has a library. It builds it by discovering the sources automatically using a source path and a naming convention (with x → x.ads). The information lands into the Ada Library Information files (.ali).
HAC has the same discovery mechanism, BTW .
If you could express your personal opinions without insulting people that would be a great.
12 Likes
I am pretty sure that Ada 83 (and I have been using Ada since about then, albeit the compilers back then often weren’t full validated implementations) supported any number of libraries. Things were much more primitive then to the point where, for instance, I (and presumably many others) had developed my own dynamic strings library. But I don’t recall any issue with connecting libraries.
At the Leuven university in Belgium we used among other VADS, the Verdix Ada Development System for what later would be called Ada 83, and it worked with multiple libraries.
Quote from the Wikipedia page https://en.wikipedia.org/wiki/Verdix:
“The Verdix Ada Development System (VADS) provided a set of tools for software developers who create complex systems. It included an Ada compiler, a visual debugger, a library management system, and an efficient runtime system.”
1 Like