I asked before if it were possible to upload projects without messing up with any alien repositories. E.g. in sourceforge you would simply push updates using rsync or sftp. The answer was no.
I guess it depends on the expectations you have for what publish means. I think you can create your own index and publish your crates to those and have your copy of alire work with that index (in addition to the community index or in place of). It won’t show up on the Alire website though, so if you want publish to make it show up on the alire website, you might have to use github for that. I don’t know if the index you setup needs to be git compatible or not though. There isn’t a good section in the docs that really to goes through setting up an index step by step. It’s in bits and pieces.
When I run help at the command line I get:
$ alr help index
SUMMARY
Manage indexes used by current configuration
USAGE
alr index [options] --add <url> --name <name> [--before <name>] | --del <name> | [--list] | --update-all | --check
OPTIONS
--add=URL Add an index
--before=NAME Priority order (defaults to last)
--check Runs diagnostics on index contents (unknown values, hosts, etc.)
--del=NAME Remove an index
--list List configured indexes (default)
--name=NAME User given name for the index
--update-all Update configured indexes
--reset-community Add the community index, or reset any local changes
DESCRIPTION
Add, remove, list and update indexes used by the current alr configuration.
Updating applies only to repository-stored indexes, in which case a pull
operation will be performed on them. An index initially set up with a
specific commit will not be updated.
URL can be one of:
- Plain absolute path: /path/to/index
- Explicit path: file://path/to/index
- git over HTTP/HTTPS: git+https://github.com/org/repo
- git over SSH: git+ssh://user@host.com:/path/to/repo
- git user over SSH: git@github.com:/org/repo
Note that there is a user@host.com option listed there, which makes me think non github urls will work (but you may still need to use git over svn or others). I’ve never tried it though.
I don’t know how they do their releases (I should try to look into it so I understand better, I just haven’t taken the time yet). That was from the master branch (originally…for some reason the forum auto changes the link shortly after I post it to point to a specific commit, even if I fix it back to master). So being in master, I assumed it was current but I was most likely mistaken.
When designs were being discussed, I recommended against becoming a wrapper for some particular/non-Ada service (e.g. GitHub) — precisely because of this.
IIRC, I recommended doing DSA and node-local mirrored-storage, relegating things like GitHub, SVN, etc to a “foreign dependency” sort of status. The idea was that the Ada system would be not of program-as-text, but as a DB-amiable datastructure: thus allowing better quality control (no storing parse-error non-programs)… sadly they chose to become a wrapper for Git.
I think someone could set up a mirror of the community index to Codeberg.org and publish to that mirror. Then someone has to open a pull request from the GitHub mirror to the original community index. Maybe that can be automated, if even having a GitHub account just for that is a concern for the contributor.
Look, using an inferior technology and software like Git is all OK to me, so long the mess remains hidden from the end user. It is like Python scripting in the GPS. Most people do not care because they do not see it. It is braindead, stupid and non-Ada, but whatever.
The same should apply to a repository interface. Give people a normal upload interface and do whatever garbage you like to do in the background. Of course, one would prefer some Ada server and Ada persistence system instead. But that is not essential and up to the maintainers, their time, their pain.
The “Workspaces” paper?
It presents a design of a version-control system which:
Essentially has continuous-integration baked-in;
Never has the “Dave broke the build” problem;
(Because changes are “merged upward” only when all children of a parent are consistent; thus the root node is the history of the compilable state of the project.)
Because the sub-units/-sets of the system are workspaces, you get a system that is amiable to distribution “for free”.
The “Adabase” paper?
Details the advantage to using a database in development, for an IDE / the APSE — combine the two, and you have distributed-database code-containers, with versions, that are at least known-parsable. (if you hook “generates a valid binary”, on your “merge-up” check, then you force everything in the repo to be fully-compilable… if you hook in “at least SILVER for SPARK units” you force all SPARK units in the repo to be at least SILVER quality, etc.)
Sure.
But the problem we have here is that because it was initially designed as glue-/wrapper-code around a particular service (Git), you simply don’t have the sort of control and consistency control that’s needed. (if it’s DB-amiable structures, and built ground-up to hold attributes like Adabase, then you could have [e.g.] a LICENSE attribute and have the database itself check for consistency across licenses, or any number of other useful functions, relegating interfacing with external tooling [like Git) to exactly that: external interfacing. You could, for example, fatten everything down and have the external-interface/-storage be the index [i.e. what Alire is now], but adding in this functionality is absurdly difficult because they’ve started off as a wrapper-service rather than having a strong notion ot the repository-code’s “TYPE” , instead vommiting out Git/text.)
Yes, an amazingly inferior one. I had experience working with ClearCase 25 years ago and was stunned how bad Git was in comparison.
One of the key features of a code control system is to forbid branches. There is no need to merge anything ever. It is especially true for Ada with its packages. You just make a new release of package and never ever let two people to check the same package = project out.
I’ve worked on systems like this before. They were horrible to work in unless you were the only developer on the project. I’m definitely more of a fan of the branch style systems, especially if you have multiple developer who might need to change relates/same files.
Which is the whole point. A subproject (Git does not even have a notion of a project, Git is just a database of assorted individual files) must be a compilation unit versioned by the system (Git cannot do that). There is no scenario when two people need to independently check out and release the same Ada compilation unit!
You never need to branch anything if you correctly organize the project as a set of versioned projects of Ada compilation units.
If the package B, with-es the package A and you are working on B, you simply use your version of A. If another guy releases new A it does not affect your work in any way until you decide to upgrade the dependency (and all other dependencies in a consistent way).
Another must-have feature is a virtual file system. You do not mess with copying files forth and back. The system simply shows you the sources and binaries of the package versions your package depends on, read only, of course. No tools needed, nothing. This includes the libraries, the toolchain/compiler everything.
Yet another must-have. The system runs the unit tests upon release. You cannot release package B without passing the tests. The system runs integration tests upon dependencies upgrade. You cannot skip that either.
No, a design change would require another project architecture, different packages etc. At this stage you will not release anything except publishing specifications.
That’s just not practical. Sometimes you have a big system with a lot of changes to do (all for the same release version), you have multiple people working on those changes and they sometimes have to change the same files.
Merging files is impractical wasting time and resources.
Furthermore it shows the level of design and thinking. You do it in terms of individual source files rather than in modules, interfaces, specifications. This is not software engineering, certainly not Ada, sorry. It is low-level tinkering Git promotes.