From mboxrd@z Thu Jan 1 00:00:00 1970 From: Pjotr Prins Subject: Re: [Feature idea] Adding wikidata, wikipedia & screenshot-url fields to package-recipes Date: Fri, 2 Nov 2018 08:24:26 +0100 Message-ID: <20181102072426.t6od5xusftivw6t6@thebird.nl> References: <20181101102150.naklct2uiujtp2rl@thebird.nl> <301f9d56-2091-2fbc-da89-c2ca53d0f580@riseup.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:34920) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1gITos-00073t-0J for guix-devel@gnu.org; Fri, 02 Nov 2018 03:24:38 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1gITon-0005zB-RK for guix-devel@gnu.org; Fri, 02 Nov 2018 03:24:37 -0400 Received: from mail.thebird.nl ([94.142.245.5]:33932) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1gITok-0005xH-0i for guix-devel@gnu.org; Fri, 02 Nov 2018 03:24:32 -0400 Content-Disposition: inline In-Reply-To: <301f9d56-2091-2fbc-da89-c2ca53d0f580@riseup.net> List-Id: "Development of GNU Guix and the GNU System distribution." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guix-devel-bounces+gcggd-guix-devel=m.gmane.org@gnu.org Sender: "Guix-devel" To: swedebugia Cc: guix-devel@gnu.org On Thu, Nov 01, 2018 at 11:33:48PM +0100, swedebugia wrote: > Wikidata is linked data and dry and by using it we can share between > distros and software building projects (conda, easybuild etc.). It > scales because the software maintainers themselves will be encouraged > to update project information - such as a reference to a mailing list > - which is the only way to really keep up-to-date in a scalable way. > Wikipedia will use that information too. Wikidata is DRY. > > First I did not understand DRY. Found > [1]https://en.wikipedia.org/wiki/Don't_repeat_yourself > Agreed, it would be nice if changes to Wikidata would be driven by the > authors of the programs and shared with leaf nodes (package managers, > etc.) Yeah, sorry for the jargon. > I agree. Though it would be good to find a way to keep queries to > wikidata to a minimum. Caching maybe. It lends itself naturally to caching. We can use fetching links for the website - that would be a good start - and later see if we can enrich package descriptions in Guix itself. In both cases the user should decide whether they want to use internet access/use a cache instead. > When you have a proof-of-concept we can even > consider writing a paper about it. > > Eh, unfortunately my guile and guix fu is not really anything to brag > about, yet ;-). I am reading up on guile and trying to understand the > code in guix. > Right now my skill level is at > * finding spelling errors and unclear text in the manual > * contribute new simple packages (about to package recoll > [2]https://en.wikipedia.org/wiki/Recoll and splint) > * adding better error messages to guix > * sharing new ideas > > This wikidata endeavor would likely take some time for me to accomplish > with a good mentor. No problem! I think it is actually a very good learning project. We can help. Start small is my advice. > First up is deciding whether the core procedures interacting with > wikidata should be in guix or as a separate module. I suggest separate > module. Agree. I think it can be a tool that is separate from Guix itself. Just start with a simple query and store that either as an S-expression or as JSON. I think (eventually) we ought to do both so other languages may use output too. Have a look at the tooling that generates the website. > Then writing client procedures to interface with the SPARQL API in > wikidata. This has already been done in python 3 (beta) see > [3]https://github.com/dahlia/wikidata gplv3+ > > We could piggyback on this client (essentially making guix dependent on > python :/) or better yet contribute to one of the existing guile sql > libraries: > * [4]https://sourceforge.net/projects/guile-simplesql/files/latest/do > wnload (unmaintained since 2014 it seems) > * [5]https://github.com/opencog/guile-dbi (active fork) > > The last one looks most promising but I did not look at the code yet. Personally I would use the Python stuff first and then slowly replace that with Guile. That way you get to results fast and we can improve over time. I personally take no issue with mixing stuff. And because it is a separate tool it is your choice anyway. I think also, initially, we should build a separate website that can display all this information. That way you have full freedom on implementation and experiments. > Will you join our Guix event at FOSDEM? This would be an interesting > working group. > > Thanks for the invitation. I will think about it. > I look forward to hone my guile and guix skills :) Please come. FOSDEM is awesome. Pj.