<Steap>mark_weaver: does "guix environment" have to connect to Hydra ?
<mark_weaver>Steap: one of the things "guix environment" needs to do is to build (or download) all of the things needed to make the build environment. so yes, it might need to connect to hydra if you have substitutes enabled.
<mark_weaver>but iirc, it first prints out a list of things that will be built or downloaded, like the other commands.
<Steap>yeah, I built all of the packages I asked for manually
<Steap>so "guix environment" should not have too much work
<lfam>Of course, now my unicode aware program does not like being run in my unicode-aware terminal, but that is a small price to pay for now. TERM= it is!
<mark_weaver>lfam: what do you mean by "does not like" ? what's going wrong exactly?
<lfam>My urxvt is from Debian. If I run my guix-provided ncmpcpp from the command line, I get "Error opening terminal: rxvt-unicode-256color." So now I have a terminfo problem?
<Steap>"building of `/gnu/store/6k1xqy1311khcp07wvfmwbq2cxfx10bq-python2-wrapt-1.10.5.drv': goal destroyed"
<codemac>others have probably better workflows though
<lfam>This method seems to fall over when the same packages already exists in gnu/packages. For that case I would use ./pre-inst-env and edit the guix-provided package definition with my local tarball's hash, but since the locales are funky I have had to rename my local packages
<lfam>So for example, I want to make a change in the recutils source code and maintain that source tree privately for the time being. But I can't install it as recutils using GUIX_PACKAGE_PATH. So I have it renamed to recutils-dev
<civodul>just mentioning that there's quite a lot of work to be done ;-)
<rekado>I think that a GNU-themed conference might reinvigorate the project as an actual technical and social project; it often seems to me that many of the GNU subprojects appear to retain the "GNU" in their name for historical reasons only.
<mark_weaver>so, in the inputs, you'd add something like ("bash:include" ,bash "include")
<mark_weaver>and then #:configure-flags (list (string-append "--with-bash-headers=" (assoc-ref %build-inputs "bash:include") "/include")) or something like that. it's not clear to me from the message you pasted which directory it wants there
<mark_weaver>the call to 'assoc-ref' will return somethign like "/gnu/store/...-bash-include-2.3.39"
<davexunit>ACTION found a small container bug... patch coming soon.
<lfam>Yeah, the upstream information is pretty sparse. But I think it wants the path to the directory containing the headers. It looks for them at configure time to decide whether or not to build this neat bash extension.
<lfam>What's a good workflow for installing local source code / tarballs with guix? Especially if they are already packaged by guix but I want to maintain my changes privately for now.
<lfam>I have been doing `guix download /path/to/file`, `guix package -L /path/to/definitions -i package_name` but that fails unless I change the name of the package
<davexunit>you'll need to change the name or version number
<mark_weaver>there are two ways to use the git version without installing it: prefix the commands with ./pre-inst-env, or make ~/.config/guix/latest a symlink to the git checkout after it's fully built.
<yrns>Ah, super helpful. And you run the daemon from the git version?
<mark_weaver>yrns: that can be done, but I normally don't. the daemon doesn't change very often, so it's fine to use an old daemon.
<yrns>Everything built, but the git version of the daemon was having trouble with glibc versions.
<mark_weaver>you can use whatever version of the daemon is most convenient
<paroneayea>davexunit: when you run "setup.py develop", if you have the virtualenv *activated* (or are using the virtualenv's python), it puts the package you're doing "setup.py develop" on on your PYTHONPATH
<paroneayea>because it changes the virtualenv's list of module directories