Re: Ada package registry?

[Shark8 <onewingedshark@gmail.com>]

On Monday, February 1, 2016 at 5:44:50 PM UTC-7, Randy Brukardt wrote:
> <olivier.henley> wrote in message 
> >1. There is a website, e.g code.dlang.org, wiki style with limited editing 
> >power;
> > enough to add your package infos, e.g JSON file with all infos, authors, 
> > name,
> > dependencies etc.
> 
> Which requires the author to do something; many of them can't even be 
> bothered to post about their libraries here (like AdaID) or send a link to 
> AdaIC? Why do you think they would use some more complex website?

Well, to be fair "posting about their libraries here" *IS* requiring the authors to be doing something.

A good tool, IMO, would handle checking and submitting. Probably without much more difficulty than something like PowerArchiver for creating ZIP archives.

> >2. Every package code base has to reside on some "handled" version control 
> >system
> >ecosystem like github, bitbucket etc.
> 
> Most likely, only one or two. Much too hard to create something that works 
> with everything, and like as not the volunteers will run out of energy long 
> before.

If the "submission tool" ensures that anything submitted is compilable, we could process/store it in a DB. The hardest part would probably be going from the intermediate-representation to the DB, something like that could be done by a tool that reads the type definitions, creates the tables, and stores all the objects.

> >3. On your machine you need an executable e.g dub.exe
> 
> One would hope that this would be handled by Gnoga and not something that 
> has to be installed. As you as you require a program, you're limited to 
> Windows and Linux and maybe Mac, and someone has to fix that program every 
> time there is an OS update.

Agreed.
But we don't need to expand the scope to include non-Ada portions of the dependencies; this would mean we wouldn't have to worry about binaries and OSes.

Naturally, having some sort of way to link to binaries/installers would be nice, but it's not requisite.

> >Using this executable, dub.exe, you can fetch code dependencies, generate 
> >solutions
> >and build libs and application with simple commands. Other commands let you 
> >control
> >all kind of stuff like the particular code version of one of your lib 
> >dependencies.
> 
> In order words, yet another tool to learn. One of the reasons I have so much 
> trouble with Linux is that you have to figure out the various package 
> managers before you can do anything -- but I usually just want to get 
> whatever I need done and move on.
> 
> ...
> BTW, this is *exactly* what I thought you meant. I find it a combination of 
> overkill and likely harm to the Ada community (by excluding large portions 
> of, by the extra work involved at a minimum).

I see your point, but I don't agree that it's likely to harm the Ada community. (Provided that it's done competently.)

> >> To have some sort of automated repository would
> >> require authors to do more: mirror their work somewhere they're not used 
> >> to,
> 
> >To use github/bitbucket/etc is mandatory. I would not hire a guy that does 
> >not
> >know or is not interested to learn git/mercurial and use 
> >github/bitbucket/etc. Not
> >being aware of these as a programmer, in 2016, only demonstrate serious 
> >lack of
> >curiosity and competencies deprecation.
> 
> I don't want to reargue this again, but all of these version control systems 
> are a serious step backwards for Ada source management from the (custom) 
> version control we use here in-house.

All of those systems could, in theory, be tied into (or handled by) the "submission tool" -- where an author could click an "update and build" which would sync his environment with the VCS and build then, if successful, push the new version onto the Ada-specific repository.


> I built a series of shell programs to provide the additional facilities that 
> are missing from every version control I've ever looked at. They provide 
> management of related but different source files (different bodies for 
> different targets), including flagging of files that need attention, as well 
> as managment of file sets for different targets. The only advantage of 
> github et. al.over what we have is collaboration, which is not relevant for 
> a propriatary code store that I would never put on-line in the first place. 
> ("Internet Security" is essentially the same sort of oxymoron as "Military 
> Intelligence" :-).

Couldn't we handle these cases if we did it ourselves? I mean we don't need to have the package-manager itself handle building and installing, instead provide an API for those specific tools to do that, so we could limit what we're interested in to what all an Ada project needs.

> I am not interested into moving to on-line systems that would require 
> significant work (to save nearly 30 years of development history), to lose 
> important capabilities, and to have less security. Change for the sake of 
> change (and that's what most of it is) is actively harmful to everyone, and 
> a massive waste of time.

I understand and agree -- however, if the system you're using is 30 years old and contains facilities that modern VCSs lack, doesn't this mean that there's an opportunity here?

> For my public projects, I have little interest in wasting time on tools that 
> have nothing to do with the project; so I use the same setups that I use for 
> everything else.

That is quite understandable; I tend to do the same myself.

> > Its a tool for the future, a community policy: new packages should be 
> > setup
> > this way so we can build more effectively, together.
> 
> Don't buy it. Especially once whatever it does becomes obsolete (and change 
> for the sake of change, the mantra of this century, will make that sooner 
> rather than later).

I think I could buy it -- the biggest issue, I think, seems to be a method for specifying the project (things like alternate bodies, etc), if we could do that then the rest is essentially protocol details, right?