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.107.167.148 with SMTP id q142mr32806213ioe.17.1454438704969; Tue, 02 Feb 2016 10:45:04 -0800 (PST) X-Received: by 10.182.42.195 with SMTP id q3mr435071obl.3.1454438704950; Tue, 02 Feb 2016 10:45:04 -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!ks5no464143igb.0!news-out.google.com!l1ni890igd.0!nntp.google.com!o2no1511991iga.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: comp.lang.ada Date: Tue, 2 Feb 2016 10:45:04 -0800 (PST) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=97.123.145.240; posting-account=lJ3JNwoAAAAQfH3VV9vttJLkThaxtTfC NNTP-Posting-Host: 97.123.145.240 References: <02241ec4-0f95-4f63-9abc-092f167eb59e@googlegroups.com> <0ed849e7-75aa-4b9c-8085-ba50014ac87c@googlegroups.com> User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: <5e723414-8c8d-4487-87ac-60d95e1b4e01@googlegroups.com> Subject: Re: Ada package registry? From: Shark8 Injection-Date: Tue, 02 Feb 2016 18:45:04 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: news.eternal-september.org comp.lang.ada:29322 Date: 2016-02-02T10:45:04-08:00 List-Id: On Monday, February 1, 2016 at 5:44:50 PM UTC-7, Randy Brukardt wrote: > wrote in message=20 > >1. There is a website, e.g code.dlang.org, wiki style with limited editi= ng=20 > >power; > > enough to add your package infos, e.g JSON file with all infos, authors= ,=20 > > name, > > dependencies etc. >=20 > Which requires the author to do something; many of them can't even be=20 > bothered to post about their libraries here (like AdaID) or send a link t= o=20 > AdaIC? Why do you think they would use some more complex website? Well, to be fair "posting about their libraries here" *IS* requiring the au= thors to be doing something. A good tool, IMO, would handle checking and submitting. Probably without mu= ch more difficulty than something like PowerArchiver for creating ZIP archi= ves. > >2. Every package code base has to reside on some "handled" version contr= ol=20 > >system > >ecosystem like github, bitbucket etc. >=20 > Most likely, only one or two. Much too hard to create something that work= s=20 > with everything, and like as not the volunteers will run out of energy lo= ng=20 > 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 fr= om the intermediate-representation to the DB, something like that could be = done by a tool that reads the type definitions, creates the tables, and sto= res all the objects. > >3. On your machine you need an executable e.g dub.exe >=20 > One would hope that this would be handled by Gnoga and not something that= =20 > has to be installed. As you as you require a program, you're limited to= =20 > Windows and Linux and maybe Mac, and someone has to fix that program ever= y=20 > time there is an OS update. Agreed. But we don't need to expand the scope to include non-Ada portions of the de= pendencies; this would mean we wouldn't have to worry about binaries and OS= es. 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, generat= e=20 > >solutions > >and build libs and application with simple commands. Other commands let = you=20 > >control > >all kind of stuff like the particular code version of one of your lib=20 > >dependencies. >=20 > In order words, yet another tool to learn. One of the reasons I have so m= uch=20 > trouble with Linux is that you have to figure out the various package=20 > managers before you can do anything -- but I usually just want to get=20 > whatever I need done and move on. >=20 > ... > BTW, this is *exactly* what I thought you meant. I find it a combination = of=20 > overkill and likely harm to the Ada community (by excluding large portion= s=20 > 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 commun= ity. (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 us= ed=20 > >> to, >=20 > >To use github/bitbucket/etc is mandatory. I would not hire a guy that do= es=20 > >not > >know or is not interested to learn git/mercurial and use=20 > >github/bitbucket/etc. Not > >being aware of these as a programmer, in 2016, only demonstrate serious= =20 > >lack of > >curiosity and competencies deprecation. >=20 > I don't want to reargue this again, but all of these version control syst= ems=20 > are a serious step backwards for Ada source management from the (custom)= =20 > version control we use here in-house. All of those systems could, in theory, be tied into (or handled by) the "su= bmission tool" -- where an author could click an "update and build" which w= ould 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 t= hat=20 > are missing from every version control I've ever looked at. They provide= =20 > management of related but different source files (different bodies for=20 > different targets), including flagging of files that need attention, as w= ell=20 > as managment of file sets for different targets. The only advantage of=20 > github et. al.over what we have is collaboration, which is not relevant f= or=20 > a propriatary code store that I would never put on-line in the first plac= e.=20 > ("Internet Security" is essentially the same sort of oxymoron as "Militar= y=20 > 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=20 > significant work (to save nearly 30 years of development history), to los= e=20 > important capabilities, and to have less security. Change for the sake of= =20 > change (and that's what most of it is) is actively harmful to everyone, a= nd=20 > a massive waste of time. I understand and agree -- however, if the system you're using is 30 years o= ld and contains facilities that modern VCSs lack, doesn't this mean that th= ere's an opportunity here? > For my public projects, I have little interest in wasting time on tools t= hat=20 > have nothing to do with the project; so I use the same setups that I use = for=20 > 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= =20 > > setup > > this way so we can build more effectively, together. >=20 > Don't buy it. Especially once whatever it does becomes obsolete (and chan= ge=20 > for the sake of change, the mantra of this century, will make that sooner= =20 > 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?