guix-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Feature idea] Adding wikidata, wikipedia & screenshot-url fields to


From: swedebugia
Subject: Re: [Feature idea] Adding wikidata, wikipedia & screenshot-url fields to package-recipes
Date: Thu, 1 Nov 2018 23:33:48 +0100

Hi :)

On 2018-11-01 11:21, Pjotr Prins wrote:
On Thu, Nov 01, 2018 at 10:44:19AM +0100, swedebugia wrote:
   Also to help us to associate new and existing packages with
   wikidata-entries we could devise a guile-programmed way to associate
   wikidata-entries to existing package objects and perhaps use this to
   populate new package-recipes created with guix import

   Guix would then be the first package manager to both be completely free
   of proprietary software and to leverage knowledge from Wikidata and WP.

   What do you think?
Absolutely the way forward. Totally excited you want to run with this!

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

People don't realise it, but in science to find the right tools for
the job is often a challenge. Wikidata will help us create sections
for tools that address certain tasks. For example variant calling in
sequencing data. I and others here have a direct stake in solving this
problem. This meta-information does not belong in Guix, so we need a
place to handle it. 
I agree. Though it would be good to find a way to keep queries to wikidata to a minimum. Caching maybe.
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 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.

First up is deciding whether the core procedures interacting with wikidata should be in guix or as a separate module. I suggest separate module.

Then writing client procedures to interface with the SPARQL API in wikidata. This has already been done in python 3 (beta) see 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:

The last one looks most promising but I did not look at the code yet.

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 :)
Cheers
Swedebugia

reply via email to

[Prev in Thread] Current Thread [Next in Thread]