Hello, so the standard library is great, babel is working great. I had a couple ideas for babel. My ultimate idea for a package manager, which is totally unnecessary at this point for babel, is some kind of peer-to-peer distributed database that automatically keeps itself updated and can't go down. I came up with that after seeing the issues scaling npm.
Not necessary to go that far I think, mainly a crazy idea. But a simpler idea (not the ultimate solution) to consider: use the .babel file contents instead of manually creating a separate package.json entry, and create an API that updates the package.json automatically when the .babel data is POSTed.
So you would run 'babel publish', babel would read the .babel file and convert it to JSON, and POST it to the API endpoint, on that server the package.json is modified, then git commands to add, commit and push the change are run.
That's an interesting idea, sounds fun to implement too heh. Maybe it will happen someday.
As for babel publish, that's already planned. It will likely use Github's API.
I mean there is always the "copy pacman" approach.
A fully distributed package manager is probably harder. I was talking to someone who works on Freenet and he was saying that guaranteeing consistency and making sure that there is a cache of data /somewhere/ is very hard. Apparently Freenet does not actually make sure data will not be arbitrarily deleted from the network and just has to rely on there being enough copies of the data that that is unlikely to happen. Since package managers have stricter consistency requirements and less strict security and anonymity requirements I am not sure going full distributed is a good idea.
I do think that having "binary" versions of packages is a good idea, in particular it would be nice to just download the latest version and not have to deal with repos that have weird detached heads.
One idea I had was to not only copy pacman but actually to use pacman. I have personally gotten pacman to compile on RHEL and MacOSX, and msys2 uses it on windows. The library it is built on is fairly standard C and there is actually a nimrod wrapper. There is also appeal in being able to use pacman to deal with native library dependencies on all platforms. Disadvantage is that pacman and its library are GPLv3 but I think stuff like package managers get to take advantage of the GCC clause.
Yet another idea is to copy CPack and have facilities that would help generate platform specific packages for various systems, so you may have the tool spit out PKGBUILDs, .deb files, windows installers, and macOS packages. There could then be a repository like CPAN that dealt with keeping all of this in sync and offering repos that users of various systems could subscribe to.
in particular it would be nice to just download the latest version and not have to deal with repos that have weird detached heads.
Babel will already do that if you specify that you want HEAD. (by writing pkgname#head).
One idea I had was to not only copy pacman but actually to use pacman.
I think Babel is already at a stage where it has enough features to be usable as a package manager. So I think it's a bit late to use pacman now and I can't see any reason to anyway. Implementing the package manager ourselves also gives us more control than pacman ever will, that said I never looked at the pacman lib so perhaps it's not as restrictive as I think it is.