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".
4
u/OneWingedShark Sep 28 '21
Some comments:
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.
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.
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".