From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,FREEMAIL_FROM autolearn=unavailable autolearn_force=no version=3.4.4 X-Received: by 10.182.56.233 with SMTP id d9mr19405024obq.2.1454267410264; Sun, 31 Jan 2016 11:10:10 -0800 (PST) X-Received: by 10.182.66.12 with SMTP id b12mr54764obt.1.1454267410217; Sun, 31 Jan 2016 11:10:10 -0800 (PST) Path: eternal-september.org!reader01.eternal-september.org!reader02.eternal-september.org!news.eternal-september.org!mx02.eternal-september.org!feeder.eternal-september.org!news.glorb.com!h5no1229506igh.0!news-out.google.com!kr2ni2785igb.0!nntp.google.com!o2no795697iga.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Sun, 31 Jan 2016 11:10:09 -0800 (PST) In-Reply-To: <02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com> Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=107.179.250.49; posting-account=MRPdDAoAAADUJmZVjnYaoafXFMadSeY1 NNTP-Posting-Host: 107.179.250.49 References: <02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <0ed849e7-75aa-4b9c-8085-ba50014ac87c@googlegroups.com> Subject: Re: Ada package registry? From: olivier.henley@gmail.com Injection-Date: Sun, 31 Jan 2016 19:10:10 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:29307 Date: 2016-01-31T11:10:09-08:00 List-Id: On Friday, January 29, 2016 at 5:27:41 PM UTC-5, Randy Brukardt wrote: > wrote in message=20 > news:02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com... > >For sure, at the moment, Ada initiatives are not gathered properly. >=20 > Definitely false. I've been maintaining lists of sources of Ada packages = and=20 > the Ada-wide search engine ever since we took over maintenance of AdaIC.= =20 First, thank you for the effort and reference. I was not aware of the relev= ance 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 fl= ourishing communities. 2. I do not mean to break the party but some links are dead or leads to dea= d ends e.g code removed from page. Not to mention that some referenced webs= ite "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 import= ant. Unity3D may be crappy code inside, I dont know, but look how they pres= ent it to you : https://unity3d.com/. Millions of people are jumping on the= ir bandwagon. So redirecting to too old and weird websites, sharing their c= ode, 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. No= t=20 > sure that any of them are relevant ... Well that is the main goal, to find relevant packages. I did the exercise t= oo and AdaID did not come up so we are not in business ... yet. https://git= hub.com/anthony-arnold/AdaID > P.S. I'm skeptical that any such repository would be kept very current.= =20 > After the organizers initially populate it, I think it's not very likely= =20 > that much updating would get done.=20 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, auth= ors, 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 s= olutions and build libs and application with simple commands. Other command= s let you control all kind of stuff like the particular code version of one= of your lib dependencies.=20 a. Every time a lib/app owner commit new code to its repo (github, bitbucke= t etc) it is "automatically" maintained at code.dlang.org because this serv= er 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 genera= te solutions and build if needs be. c. Once in that loop, you can share your package that reference package tha= t reference package that refer... =20 > To have some sort of automated repository would=20 > 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/bitbuck= et/etc. Not being aware of these as a programmer, in 2016, only demonstrate= serious lack of curiosity and competencies deprecation.=20 > What are the odds that such a repository could figure out how to pull fil= es=20 > 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. >=20 > 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 an= d/or by deduction. I would go even further, like special entries in the JSO= N 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 b= e use as an end-user application, be it coded in the native language or ano= ther one. Maybe -> "alien-libs": ["sqlite3"] would be clear enough, at leas= t to consult the doc for the meaning of alien-libs. :)