<codemac>is there a way to build a guix package that is not in GUIX_PACKAGE_PATH?
<codemac>When I'm developing packages, it gets very frustrating that these in flux and generally broken packages break the rest of my `guix` command usage. Am I doing it wrong?
<iyzsong>codemac: yes, I think the '-L, --load-path=DIR' option do the trick.
<davexunit>sneek: later tell codemac to build a package without using the module system, you can do: 'guix build -e '(primitive-load "file.scm")'', where "file.scm" is a file containing Scheme code that evaluates to a package object.
<civodul>Steap: did you already have a patch for python-minimal + Tk?
<rekado>xd1le: there is no central site for a "community managed list of package definitions". Usually, we just accept new definitions. I cannot think of one instance where a patch adding a package definition for free software was rejected.
<rekado>xd1le: even though I personally do have a list of package definitions that won't be added to Guix I only use it as a last resort and for things that are incompatible with the project goals.
<rekado>when you have a package that seems useful and complies with the rules (e.g. not containing non-free software, not recommending non-free software, etc) it is likely to be accepted.
<civodul>it's in the project's interests to accept new package definitions
<xd1le>rekado, civodul: thanks. i only want to use free software so i don't think that would be an issue. my thought was how much your build farm can handle, and if it's therefore just for essential packages.
<xd1le>i have a question. i am using guix on arch linux. i am wondering about installing packages via guix that have already been installed on the system via pacman (arch's default package manager).
<xd1le>is it appropriate to keep both installed, or should i uninstall the one that was not installed via guix?
<xd1le>as in, can gnu/linux in general work like that?
<xd1le>i understand that the first one under the $PATH will be used, so I can just put the guix-profile/bin before everything else, but anything else to consider?
<iyzsong>xd1le: yes, you could (and should) keep both installed. packages installed by guix are all under store (/gnu), it won't confuse the host distro.
<rekado>xd1le: there should not be any conflicts. What *could* trip you up is if you had LD_LIBRARY_PATH set to system libs when running Guix software. Or having PYTHONPATH set such that system stuff is listed first, but you're using Guix Python.
<rekado>so it's not just PATH that needs to have items in the correct order but also other environment variables.
<civodul>ACTION is afraid of seeing the "faulty RAM" excuse popping up too often ;-)
<efraim>er, right. nevermind, don't know what i was thinking when I wrote that :)
<xd1le>how are upstream updates to packages handled?
<xd1le>is there some sort of automated system set up, or is it more like a maintainer of a package has to check manually for an update?
<xd1le>i'm asking because ghc on guix is still on 7.8.4, but the latest release (months ago) is 7.10.2
<taylanub>xd1le: there's "guix refresh" but AFAIK it isn't continuoutly executed by anything; guix developers need to use it. I also never used it and don't know how well it works. for GNU packages conforming to GNU packaging conventions, guix checks automatically whether there's a newer version every time a version is installed, and notifies the user that there's a newer version.
<taylanub>it shouldn't be hard to set up a system that continuously looks for new versions and keeps an updated list of outdated recipes
<xd1le>taylanub: thanks. I guess it depends on the package? for example, one could check for the existence of any new tags on the origin remote if the package is using git. or is there a better way to check for updates?
<xd1le>so I guess the solution is that people can just send patches with updated package definitions if a package they use is outdated? or are there designated 'maintainers' of packages?
<rekado>there are no designated maintainers, but sometimes the original contributor of a package may have additional information and can weigh in on discussions about updates.
<rekado>to update a package definition anyone could send a patch, and that's often how it's done.
<xd1le>is there some sort of policy on how 'stable' guix wants packages to be? for example, in nix there is stable and unstable 'channels'. does guix always try to have the latest release, or is there some sort of 'testing' period before an update on hydra is available?
<efraim>we don't have a stable and unstable channel, we have our main branch and a couple work-in-progress branches for new features and a core-updates branch that would result in a huge number of rebuilds.
<efraim>so... qpm is for qt modules you might want while writing a qt app?
<taylanub>xd1le: if a build recipe still builds after updating the version and doesn't have any obvious problems, then it will be accepted by guix upstream. by the time guix 1.0 is out, maybe there will be a 'stable' branch which 'guix pull' will use instead of the master branch...
<sneek>codemac, davexunit says: to build a package without using the module system, you can do: 'guix build -e '(primitive-load "file.scm")'', where "file.scm" is a file containing Scheme code that evaluates to a package object.
<codemac>The answer I think at some point will to just have a 'locale-user' package that is optional that contains the targets / dependencies to build a locale-archive that we can build locale to look for.
<codemac>because this guixsd vs user thing will become difficult to compile for locales and other system level configurations that binaries expect to find when they aren't in fact installed at a system level.
<yrns>Use of LOCPATH precludes use locale-archive, yeah?
<yrns>I couldn't get it to work with the system locales.
<codemac>`locale -a` specifically reads out of a locale archive, so regardless of the fact that it launches successfully using your locales, it can't list them
<codemac>it's supposed to only print what you localedef --archive-add or whatever, not just what folders are installed.
<yrns>Ah. And /run/current-system is only for GuixSD?