Re: Ada package registry?

[olivier.henley@gmail.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.

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. Not to mention that some referenced website "are yelling" 1997 abandoned code/project. 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".

> 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

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

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.
2. Every package code base has to reside on some "handled" version control system ecosystem like github, bitbucket etc.
3. On your machine you need an executable e.g dub.exe

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. 

a. Every time a lib/app owner commit new code to its repo (github, bitbucket etc) it is "automatically" maintained at code.dlang.org because this server only needs to know where to check for a particular package.

b. Dub.exe, on your machine, talks to this server and is capable of issuing git commands. Dub asks for some package, server gives infos and from there dub.exe drives git to fetch code, to a particular version, and then generate solutions and build if needs be.

c. Once in that loop, you can share your package that reference package that reference package that refer...
 
> 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. 

> 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. Its a tool for the future, a community policy: new packages should be setup this way so we can build more effectively, together.

On Sunday, January 31, 2016 at 10:56:07 AM UTC-5, Mart van de Wege wrote:

> This is not unique to Ada. Perl also has packages that require non-Perl
> libraries to be available, like XML::LibXML and Text::CSV::XS. The first
> has a dependency on libxml2, the second brings its own C code that must
> be compiled and then accessed from the Perl module.
> 
> In both cases a hard build dependency on a working gcc environment
> exists; it is the end-user's responsibility to make sure it does exist
> and that the proper header files for the dependencies are installed.

Yeah, its common practice to mention external dependencies in the README and/or by deduction. I would go even further, like special entries in the JSON that explicitly mentions the need for alien stuff. With DUB for example, you find a generic line like -> "libs": ["sqlite3"] inside the json config file... but we say/label "lib" for any piece of code that is not meant to be use as an end-user application, be it coded in the native language or another one. Maybe -> "alien-libs": ["sqlite3"] would be clear enough, at least to consult the doc for the meaning of alien-libs. :)