Re: Ada package registry?

["Randy Brukardt" <randy@rrsoftware.com>]

<olivier.henley@gmail.com> wrote in message 
news:0ed849e7-75aa-4b9c-8085-ba50014ac87c@googlegroups.com...
>On Friday, January 29, 2016 at 5:27:41 PM UTC-5, Randy Brukardt wrote:
>> <olivier.henley@gmail.com> wrote in message
>> news:02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com...
>> >For sure, at the moment, Ada initiatives are not gathered properly.
>>
>> Definitely false. I've been maintaining lists of sources of Ada packages 
>> and
>> the Ada-wide search engine ever since we took over maintenance of AdaIC.
>
>First, thank you for the effort and reference. I was not aware of the 
>relevance of AdaIC. But...
>
>1. The fact that a new user is not "naturally" directed to AdaIC is a good 
>sign the
>community is not properly organised... in comparison with other flourishing 
>communities.

I'd agree with that, but there's nothing new about that. If you like herding 
cats...try an Ada community initative. Not recommended for the faint of 
heart...

>2. I do not mean to break the party but some links are dead or leads to 
>dead ends
>e.g code removed from page.

Surely. I hand-check all of the links that come up dead (or sites that 
change to just one page, which typically means they've turned into a link 
parking site), but it's impractical to check every link all of the time. If 
the links work, I'd have no reason to look at them.

>Not to mention that some referenced website "are yelling" 1997 abandoned 
>code/project.

So what? Good Ada code doesn't suddenly become useless because it's old. 
Good libraries don't NEED any maintenance, and Ada's been around since the 
early 1980s. Obviously, it depends on what you're looking for; if it is 
something relatively new or changable, dead is not good. If it's an FTP 
library, it probably doesn't matter when it was created.

I'm not going to try to judge "goodness" of code, 'cause very little of it 
meets MY standards.

> I know we should not and can not juge code by its packaging but we also
> know how presentation is important. Unity3D may be crappy code inside, I 
> dont
> know, but look how they present it to you : https://unity3d.com/. Millions 
> of people are
> jumping on their bandwagon. So redirecting to too old and weird websites, 
> sharing their
> code, is not a good idea when your goal is to promote the idea that Ada is 
> "actually relevant".

People who are over-interested in "presentation" are not likely to be 
interested in Ada, IMHO.

>> When I stuck "UUID" into the Ada-wide search engine, I got 6 (!) hits. 
>> Not
>> sure that any of them are relevant ...
>
>Well that is the main goal, to find relevant packages. I did the exercise 
>too and AdaID did
> not come up so we are not in business ... yet. 
> https://github.com/anthony-arnold/AdaID

Probably because there is no web page explaining what it is. (And I can't 
index github.com with the current tools; that should change with the next 
generation.) I don't generally link directly to repositories, because 
everything needs more explanation than one line. (Sourceforge is an 
exception, as it includes nice web pages to front the repository.)

...
>> P.S. I'm skeptical that any such repository would be kept very current.
>> After the organizers initially populate it, I think it's not very likely
>> that much updating would get done.
>
>Yes it would. I think you underestimate what is meant by package repository
> and/or package manager, at least like DUB:

I think you overestimate the effort that most Ada programmers will put into 
such things...after all, we've had AdaHome, AdaPower, AdaIC, and probably 
others which such things, and they've all (except AdaIC) died from neglect.

>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?

>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.

>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.

>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).

>> 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.

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" :-).

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.

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.

>> What are the odds that such a repository could figure out how to pull 
>> files
>> from the version control on RRSoftware.Com and Ada-Auth.org, for 
>> instance?
>
>It does not matter if not ALL sources are listed.

Actually, it does. A tool that includes 30% of the available source will 
make the listing on AdaIC look robust!

> 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).

                            Randy.