<rekado_>nee`: do any of these variables contain more than one directory? There used to be a bug relating to the variables that would make them hold not one path but a colon-separated list of directories.
<nee`>rekado_: yes, GIT_SSL_CAINFO, does. Thank you, I'll try that out in the evening.
<rekado_>paroneayea: hah, you were not kidding about the mullet guy in the video! Thanks for sharing!
<brendyn>There is are a set of fonts distributed as a single .zip containing 6 ttf files, 3 of one style, 3 of another style. both chinese fonts. would it be best to have them all install as a single package?
<jsierles>been looking at Guix here at nextjoural.com, where we're trying to build a platform for reproducible research
<lfam>Ah, several people / institutions are using Guix for this
<jsierles>looks really great and fits with our plans. I just had a few doubts about the direction. is there an over-arching goal to add other languages along with their available packages - in other words, to replace a language's own package manager?
<jsierles>for example, i see there are a lot of python modules already packaged up
<jsierles>our main challenge now is making reproducible builds that include all the modules people are using. like in python or Julia
<bavier>jsierles: the ultimate goal is to have most packages in Guix proper, but language package managers should still work alongside Guix
<jsierles>ok. would you say that by bringing a module into the guix space, its installation becomes more reproducible than with the language's own package manager?
<bavier>jsierles: in Guix the dependency tree of a package is fixed and benefits from any reproducibility of those dependencies
<bavier>whereas with many language packagers the dependencies can shift without much notice
<jsierles>alright. it seems like it would be an uphill battle to support so many packages from different languages
<bavier>jsierles: bit-for-bit build reproducibility is a work-in-progress for many packages, but Guix has several tools for checking reproducibility