IRC channel logs


back to list of logs

<mark_weaver>Steap: can you build anything at all?
<mark_weaver>maybe the daemon is stuck somehow. never had that happen to me though.
<Steap>mark_weaver: yeah, I can build stuff
<Steap>this is weird
<lfam>mark_weaver: You have cut the Gordian knot. Thank you!
<mark_weaver>lfam: \\o/
<mark_weaver>you're welcome!
<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"
<Steap>^ what does that mean exactly ?
<mark_weaver>Steap: I think it happens if something went wrong elsewhere, and then all the other pending jobs are aborted.
<mark_weaver>lfam: I have found that different distros seem to know about different sets of TERM values.
<mark_weaver>e.g. when I ssh to a Debian machine from a screen session in GuixSD, Debian doesn't know about "screen-xterm", and I need to set TERM to just "screen".
<mark_weaver>and maybe there are problems in the other direction as well.
<Steap>mark_weaver: oO
<lfam>Yes, I have to set TERM=rxvt when logging into centos machines
<lfam>Oh man, the guix provided rxvt-unicode is all wide unicode characters. Makes the 80-character limit quite necessary ;)
<mark_weaver>ACTION goes afk for a while
<lfam>Hmm, my guix provided programs have proper locales now, but `guix environment guix` still fails the locale assertion :(
<Steap>seems to be working now, weird
<codemac>Go package is almost complete! Now onto my last error :( validating RUNPATH fails on cgo.
<codemac>can almost use guix for all my go development :)
<lfam>codemac: I'm glad to hear of your progress!
<lfam>I have a few Go programs I'd like to package
<codemac>well - we need a 'go-build-system' as well
<codemac>and most go packages will have to produce a 'pkg' output that other go programs can use at build time due to the .a static linking stuff.
<lfam>I see
<codemac>but yes, I'm very excited :)
<lfam>What's your workflow for installing local source code / tarballs with guix?
<lfam>I have been doing `guix download /path/to/file`, `guix package -L /path/to/definitions -i package_name`
<lfam>Is that the best way?
<codemac>Yeah, I just manipulate my GUIX_PACKAGE_PATH
<codemac>I have $HOME/code/guix-pkgs/{tmp,src}
<codemac>src being things I always have in it, and tmp being things I'm working on.
<codemac>then I just do guix package -i pkg
<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
<lfam>I don't like that
<codemac>Hmm.. yeah if it's in a different module I'd imagine that guix could find a package based on a module path but I'm not sure.
<codemac>I usually am updating or adding new ones right now
<lfam>Yes, this recutils thing is the first I have this issue
<lfam>But `guix environment` failes due to locale issues, so I can't use ./pre-inst-env
<xd1le>there are packages with the 'MIT' license.
<xd1le>for guix, what should be put there, 'expat'/'x11'?
<davexunit>xd1le: yes, the list is narrowed to those two.
<davexunit>they both come from MIT
<davexunit>which is why we (and GNU) do not call any license *the* MIT license
<davexunit>check the relevant license text in that program to determine if its expat or x11
<xd1le>davexunit: okay, thanks.
<xd1le>so i'm trying to package qutebrowser for guix and i get:
<xd1le>guix package: warning: failed to load '(python-qutebrowser)':
<xd1le>ERROR: no code for module (python-qutebrowser)
<xd1le>after doing `guix package -s qute`
<xd1le>btw, this is my first attempt at packaging something for guix
<davexunit>looks like you are trying to import python-qutebrowser as a module
<davexunit>but I'm guessing it's a variable name
<xd1le>i set GUIX_PACKAGE_PATH so why can't it find it?
<xd1le>if you'd like, i can link you to the actual file..?
<davexunit>oh this is a separate module.
<davexunit>what is the path to that file, relative to GUIX_PACKAGE_PATH?
<davexunit>guile module names correspond precisely to files on disk
<xd1le>it is in GUIX_PACKAGE_PATH directly
<davexunit>okay that's your first problem
<xd1le>the file is called python-qutebrowser.scm
<davexunit>search path variables are colon delimited lists of directories
<xd1le>ah so i need to learn scheme
<davexunit>no this is just a general unix thing
<xd1le>okay np.
<davexunit>export GUIX_PACKAGE_PATH=/path/to/package/dir
<xd1le>okay wait, here is the file:
<xd1le>and this is how i set the package path:
<xd1le>so i think i need to put it under a subdirectory `my-packages`?
<xd1le>okay it works, figured it out.
<xd1le>thanks again.
<davexunit>yeah that code looks right
<davexunit>happy hacking
<paroneayea>oh btw
<paroneayea>mark_weaver: not sure I got to say it
<paroneayea>but it was so great meeting you!
<mark_weaver>paroneayea: thanks, it was great to meet you too! :)
<codemac>any tips on what to do about a .a that references dynamically? This is built by the go toolchain so a lot of the normal hacks haven't worked :(
<codemac>runtime/cgo.a has a dynamic reference
<mark_weaver>codemac: you'll need to find the code that loads, and patch it to instead use a fixed absolute path name of the form "/gnu/store/..."
<codemac>yeah, I'm trying, I think it relates to pthread usage, I'm not entirely sure
<codemac>I found the .o / .a, but go doesn't produce the type you expect
<mark_weaver>I would search the source code for "libgcc_s"
<codemac>it doesn't exist anywhere, libgcc_s is something gcc adds based on whether or not you use certain functions
<mark_weaver>does go use gcc?
<codemac>no, go has it's own compiler EXCEPT for something it calls 'cgo' where it compiles with gcc, so it's hard to keep track of.
<codemac>I'll brb
<sneek>Its been said that sneek is a *silly* bot
<xd1le>the package i want to package does not have a configure script
<xd1le>is there a way to skip the configure phase, or what should i do?
<xd1le>nvm i suck at reading
<sneek>Last time I checked sneek is a good boy
<codemac>so when I compile it on arch, it doesn't link to libgcc_s at all
<xd1le>is there documentation anywhere for what maintainer objects look like?
<codemac>maintainer objects?
<xd1le>sorry, "maintainers":
<codemac>oh - I've never used that
<xd1le>ah nvm, found an example in the guix source code
<xd1le>looks like just a list of email addresses
<xd1le>codemac: are you compiling via `go build`?
<xd1le>because go isn't packaged in guix is it?
<codemac>I'm packaging the go compiler suite right now
<codemac>* :)
<xd1le>you mean like a replacement for go get/install ?
<xd1le>actually nvm, go needs to be packaged for that anyway. gl
***jalle is now known as jockej
<rekado>cannot download texlive-texmf-2015; I get to 545.2MiB and then get "bzip2: Compressed file ends unexpectedly"
<lfam>The source tarball?
<lfam>Does anyone have an example of specifying different outputs of a package as inputs to another package? I'm trying to include bash:include as a propagated input
<civodul>Hey, Guix!
<lfam>Good morning!
<lfam>civodul: Can you point me to any examples of how to specify different outputs of a package as inputs to another package? I'm trying to include bash:include as a propagated input to recutils
<civodul>lfam: abiword depends on the "bin" output of glib, for example
<lfam>Thank you! Maybe this will bring readrec to life...
<rekado>re conf.nixos and the various single-topic conferences: I would love to see a GNU conference where the state of the various GNU subprojects is presented and discussed.
<rekado>maybe like the GHM, but bigger.
<civodul>lfam: i wanted to do that, but i think some of the Bash headers are missing or something
<civodul>well, you'll tell us :-)
<civodul>rekado: yes, that's the ideal
<civodul>in practice, it seems that, say, Octave's conf alone brings more people than a GHM
<civodul>1% of those at the GNU Tools Cauldron come to the GHM
<civodul>i'm not saying we should give up tho
<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.
<rekado>I'd love to see this change.
<mbuf>rekado, +1
<civodul>rekado: yes, agreed; that was the idea behind GHMs
<xd1le>is it bad to leave the "warning: failed to install locale: Invalid argument" warning and not do anything about it?
<xd1le>i ask because solving it seems to bring more problems, and it doesn't seem to have any effect
<xd1le>i use the default en_US locale normally anyway
<civodul>xd1le: see but avoid this suggestion if you are using current master
<xd1le>nah i think i'm using 0.8.3, but i did that that and it 'messes up' my terminal (and maybe other things)
<xd1le>so my question is, would any packages installed via guix like this, have any unexpected behaviour or anything?
<xd1le>i just switch my entire wm to the one installed via guix, but it seems to work fine.
<xd1le>(that does get rid of thing warning though)
<rekado>xd1le: are you really using 0.8.3 or did you start with 0.8.3 and then did "guix pull" or updated to the latest version from git? 0.8.3 is already quite old.
<xd1le>rekado: i did do guix pull yesterday, does that update guix itself as well?
<xd1le>perhaps that explains it.
<xd1le>civodul: is there a workaround atm for current master? or just leave be?
<xd1le>i did the standard binary install at first though.
<xd1le>rekado: `guix --version` still says 0.8.3 though.
<rekado>xd1le: when you do "guix pull" you get a symlink ~/.config/guix/latest, which points to the latest guix version at the time, in the store.
<rekado>did you do "guix pull" as the same user?
<xd1le>no, i don't think so.
<xd1le>i installed guix initiallly as root, as instructed
<xd1le>i then had to chown /var/guix/profiles/per-user/<my-user> to my normal user
<xd1le>and then i could use guix as my normal user and did guix pull from there
<rekado>if you did "guix pull" as a regular user this very user should be using the latest version then.
<xd1le>rekado: okay cool.
<xd1le>i'll just let it be then until the documentation is updated.
<civodul>xd1le: you're not using GuixSD, right?
<xd1le>civodul: correct, arch linux atm.
<xd1le>civodul: while you're here, when i lint, i get: "the source file name should contain the package name". but the source file name does contain the package name... so what does it mean?
<civodul>xd1le: 'lint' is for developers and it checks for various conventions in package definitions
<civodul>this one is about a convention on how to name patch files (?)
<civodul>ah no, source file names
<civodul>well anyway
<xd1le>civodul: yep, this is the file:
<xd1le>so i did `guix lint bspwm` and that's the only warning. because i want to submit a path to guix
<civodul>ah nice
<civodul>so the problem here is that the basename of the URL is "0.9.tar.gz"
<civodul>this is what 'lint' reports
<xd1le>ah i see.
<civodul>to fix it, you must add a 'file-name' field in 'origin' to force the file name to be "bspwn-0.9.tar.gz"
<civodul>before submitting, please add a comment to justify #:tests? #f
<civodul>just letting you know in advance ;-)
<xd1le>there is no `check` target in the Makefile.
<xd1le>so just say that there are no tests?
<xd1le>also, should it be `(file-name "bspwm")` or `(file-name "bspwm-0.9.tar.gz")`?
<xd1le>nvm, figured it out. lint does not emit warning with the latter, but does with the former.
<rekado>xd1le: possibly better: (file-name (string-append name "-" version ".tar.gz"))
<xd1le>rekado: yep, just for brevity
<xd1le>rekado: to clarify, the make-flags over there are the right way to do it?
<xd1le>or is there a 'better' way. i.e. i thought that guix would handle this itself.
<xd1le>because otherwise i get "cc: command not found" when building
<rekado>setting CC=gcc in make-flags is correct.
<rekado>we do this in a couple of other packages.
<rekado>this is because the GCC package does not by default install "cc", but many distributions do install it as an alias to "gcc".
<xd1le>ah i understand. thanks.
<xd1le>although, if you look here:
<rekado>one note about your packages: when preparing patches for Guix it may be a good idea to add your package for "bspwm" to the "wm.scm" module.
<xd1le>my understanding was that this should be invoking gcc...
<xd1le>rekado: yep
<xd1le>actually, sometimes people install sxhkd separately to bspwm (bspwm also depends on sxhkd), should sxhkd also go in wm.scm?
<xd1le>because it's not technically a wm
<rekado>xd1le: hmm, "CC ?= gcc" means that CC=gcc unless otherwise defined. This should be sufficient. I don't know what's wrong here.
<xd1le>yes, same...
<rekado>xd1le: re "sxhkd" I think it would fit to "xdisorg.scm" where we have similar programmes.
<xd1le>rekado: ah yes, it's like an alternative to xbindkeys. thanks.
***davi_ is now known as Guest63187
<mark_weaver>civodul: interestingly, the guix-0.8.3 builds are succeeding on core-updates (x86_64 and mips64el so far), although they consistently fail on master.
<mark_weaver>I wonder why
***davi_ is now known as Guest48947
<mark_weaver>ah, maybe it has to do with locales
<civodul>mark_weaver: yes, LOCPATH
<civodul>the LOCPATH nightmare arrrrrghhh!
<civodul>new news!
<civodul>where Steap talks about Python goodies
<paroneayea>oooh fun re: guix-tox
<paroneayea>argh re: locales!
<rekado>(is the space in "Bonjour !" correct?)
<civodul>yes, that's French typographic conventions
<civodul>glad you asked ;-)
<rekado>ah, good to know.
<Steap>rekado: you have no idea how hard it is for us to write "Hello!" without the space
<silverwolf>Steap: You guys just made me realize I was not writing french the good way then :/ (being french, shame on me)
<alezost>is it for "?" and "." as well?
<Steap>alezost: "?" but not "."
***francis7 is now known as fchmmr
***fchmmr is now known as francis7
<Steap>alezost: also, we write "foo : bar", not "foo: bar"
<alezost>cool, I learnt French at school, but I never knew about such things :-)
<efraim>just be glad it all goes left to right
<civodul>the rule is: space around "double punctuation" (colon, semicolon, question mark, etc.)
<efraim>alternating left to right and right to left languages drives most programs crazy
<civodul>i can imagine
<Steap>alezost: yeah, I think it does not matter that much
<Steap>Writing "Hey !" instead of "Hey!" in English is bad, but nobody really cares :)
<efraim>your write, noone notices two much
<paroneayea>suddenly I can't compile guix
<paroneayea>checking for libgcrypt shared library name... -lgcrypt/libgcrypt
<paroneayea>checking whether -lgcrypt/libgcrypt can be dynamically loaded... no
<paroneayea>configure: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'.
<civodul>paroneayea: could you: grep guix_cv_libgcrypt_libdir config.log ?
<civodul>paroneayea: what about: libgcrypt-config --libs | sed -e "s/.*-L\\([[^ ]]\\+\\)[[[:blank:]]]\\+-lgcrypt.*/\\1/g"
<paroneayea>I wonder if this is due to a recent apt-get upgrade
<paroneayea>I'm on debian jessie
<civodul>paroneayea: sorry, should have been: sed -e "s/.*-L\\([^ ]\\+\\)[[:blank:]]\\+-lgcrypt.*/\\1/g"
<civodul>oh, i see
<paroneayea>could be messed up by the line wrap but I'm getting
<paroneayea>sed: -e expression #1, char 43: Unmatched ( or \\(
<civodul>paroneayea: could you try this patch:
<paroneayea>civodul: trying
<paroneayea>checking whether -lgcrypt/libgcrypt can be dynamically loaded... no
<paroneayea>configure: error: GNU libgcrypt does not appear to be usable; see `--with-libgcrypt-prefix' and `README'.
<paroneayea>same bug
<paroneayea>maybe I should try a make distclean
<civodul>no no
<civodul>what's guix_cv_libgcrypt_libdir this time?
<civodul>so you applied the patch and typed "make", right?
<paroneayea>I typed ./configure
<civodul>ah you need to run "make" first
<paroneayea>trying with just "make"
<civodul>to regenerate 'configure'
<paroneayea>okay that fixed it
<paroneayea>thx civodul :)
<civodul>cool, thanks for the report :-)
<civodul>i'll push it shortly
<paroneayea>civodul: np! know what it was?
<civodul>yes, on an FHS distro, "libgcrypt --libs" does not show any "-L" switch
<civodul>but the recent auto-detection logic that iyzsong & i added assumed that there's a -L flag
<paroneayea>got it :)
<paroneayea>thanks civodul !
<paroneayea>oh, now I have a new error
<paroneayea>new and exciting gcrypt related errors ;)
<civodul>oh, what error?
<civodul>exciting, indeed!
<civodul>could you try: make V=1
<civodul>so we get more info
<civodul>paroneayea: could you try: ?
<paroneayea>civodul: trying...
<paroneayea>civodul: still compiling but I think all is probably well at this point
<paroneayea>I used the "it's compiling" moment as an excuse to work my way through a chapter of The Seasoned Schemer :)
<bavier>civodul: ISTR that the gcrypt libs aren't passed to the linker correctly
<bavier>lemme see if I can find the patch I had...
<bavier>probably not kosher to put LIBS into LDFLAGS though
<paroneayea>civodul: compiled and works again
<paroneayea>I suggest pushing those patches
<chil>It's possible to set kernel options in GuixSD? I see 'kernel-arguments' and 'initrd' in the manual, but no mentions for changing CONFIG_* stuff
<paroneayea>maybe more gpg signing of commits would be helpful in guix
<davexunit>yeah probably a good idea
<davexunit>yup. not good.
<paroneayea>unrelated: time to package python-pyld for guix.
<paroneayea>gonna ship this activitysreams library with a package.scm
<davexunit>name it 'guix.scm', though. :)
<paroneayea>davexunit: will do
<davexunit>someone convinced me that this was a better convention
<davexunit>jao from geiser, actually.
<paroneayea>I agree it seems nicer
<davexunit>ACTION pushes new 'guix environment' exec syntax patches
<davexunit>one more issue out of the way for 'guix environment --container'
<davexunit>alright, lunch break over.
<paroneayea>davexunit: btw, I notice sly and haunt both do
<paroneayea> (source ".")
<paroneayea>in their in-package definition
<davexunit>that's old
<davexunit>and invalid
<paroneayea>yeah I was running into issues :)
<davexunit>set to #f if you have no origin
<paroneayea>ok I'll git pull
<davexunit>check this out:
<paroneayea>davexunit: hm, for the "universal virutalenv" purposes, I would like that package to somehow end up on the PYTHONPATH, basically run develop on the current directory
<davexunit>that's beyond the purposes of 'guix environment' I think
<paroneayea>davexunit: hm
<davexunit>'guix environment' gets you prerequisite packages
<paroneayea>davexunit: right.
<paroneayea>davexunit: but, I do want to advance our "universal virutalenv" argument
<paroneayea>so there may be a way to do this.... I'd like to see if I can figure it out....
<davexunit>this is what the build system is for
<davexunit>in my projects, and guix, I run 'guix environment whatever'
<davexunit>and then my usual dev workflow:
<davexunit>./configure; make; etc.
<paroneayea>davexunit: right... I guess for python it's
<paroneayea>"python develop"
<paroneayea>but the problem is
<paroneayea>that mutates things outside the current directory
<davexunit>what does it do?
<paroneayea>unless you have a virtualenv in-directory, like we do for mediagoblin hacking
<davexunit>sounds bad.
<paroneayea>davexunit: so, a few things. You need to get all the modules of *your package* on the PYTHONPATH, yeah?
<davexunit>that's what we use 'pre-inst-env' for in Guix.
<paroneayea>also, running " develop" or " install" may trigger some hooks, eg making some scripts like "gmg" available
<paroneayea>davexunit: right, we need an equiv basically.
<davexunit>can't you just add PWD to PYTHONPATH?
<paroneayea>davexunit: sort of, though it won't make those scripts available.
<davexunit>guix's pre-inst env also adds the 'scripts' directory to PATH
<paroneayea>davexunit: (also there may be other jiggery that happens under the hood when develop/install is done.)
<davexunit>so that you can do ./pre-inst-env guix
<paroneayea>davexunit: I suppose a pre-inst-env script could also be written just the same.
<paroneayea>I need to think about it.
<davexunit>yeah, looks like the python build system is doing some bad things that need fixing.
<paroneayea>davexunit: it might be that there's a really good way to move forward. I'm going to think about it.
<davexunit>okay. hope you find a good answer.
<paroneayea>davexunit: I'll let you know more as I go!
<civodul>paroneayea: thanks, i'll push the patches
<paroneayea>davexunit: here's an idea
<paroneayea>davexunit: a gexp which builds a derivation that's basically a script in the user's path
<paroneayea>but not in the directory
<paroneayea>in the path itself
<paroneayea>that sets up appropriate PYTHONPATH and etc
<davexunit>the issue I have with that is that it seems like something that should exist independent of guix.
<paroneayea>davexunit: maybe
<davexunit>and that script will need to know the absolute path to the source tree
<davexunit>among other things
<davexunit>I don't want to shoot down the idea or anything, but I'm just not sure about it.
<davexunit>I don't know enough about how the python build system works
<davexunit>I'd like to better understand why projects using the autotools have so such issues but python projects do.
<lfam>I want to set a configure flag for building recutils that provides the path to the bash headers that should be packaged as bash:include. How would I get that path? The imperative example is here:
<lfam>Also, I believe this would count as a propagated input. Is that correct?
<mark_weaver>lfam: it only needs to be a propagated input if recutils will export header files that include bash headers.
<davexunit>lfam: doesn't seem like it would need to be propagated
<mark_weaver>lfam: I would start by making it a normal input
<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
<davexunit>to distinguish them
<lfam>Right, the version number. That makes sense.
<lfam>So `guile build --expression=(...)` would involve putting the entire package definition on the command line?
<mark_weaver>lfam: my preferred method is to run 'guix' out of a git checkout on my private branch. I periodically rebase my private branch on top of upstream master.
<mark_weaver>that allows me to easily maintain arbitrary local modifications to guix
<mark_weaver>and this also allows easy upstreaming of my changes when they are ready
<yrns>If I have a binary installation (0.8.3), and a version from git, is it safe to have them both operate on the same store?
<mark_weaver>yrns: yes
<mark_weaver>but you'll need to pass --localstatedir=/var to configure in order to use the same store
<yrns>So I never really need to 'install' the git version?
<mark_weaver>right, I never do
<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
<mark_weaver>an old daemon can build the latest software.
<lfam>What's the easiest way to get a .drv path so I can do `guix build --log-file`?
<lfam>Found it: -d, --derivations return the derivation paths of the given packages
<mark_weaver>you can also just pass a package name to "guix build --log-file"
<paroneayea>Steap: ping
<paroneayea>Steap: at some point when around, I'd like to brainstorm about more "guix as virtualenv replacement" stuff with you
<Steap>paroneayea: well, go on
<paroneayea>Steap: so, one usage of virtualenv is for deployment, getting an isolated area with all dependencies
<paroneayea>another area, as davexunit and I were discussing above, is development
<paroneayea>eg, you might do
<paroneayea>python develop
<paroneayea>when in the virtualenv
<paroneayea>and not only might that put your current project on the PYTHONPATH
<paroneayea>it also might put some "scripts" there
<paroneayea>eg, mediagoblin has a "gmg" command
<Steap>This is such a terrible idea for deployment, basically as bad as using Docker
<paroneayea>Steap: not for deployment
<paroneayea>just for development.
<paroneayea>Steap: and I'm not saying use virtualenv
<paroneayea>I'm saying, trying to replace this use case with guix
<Steap>yeha, I'm saying that the "deployment" use case is terrible
<Steap>do people really do that ?
<Steap>Do they use that dh_venv stuff in Debian for instance ? :p
<paroneayea>Steap: mediagoblin's development instructions say to do something like this, and so do most "get started with hacking" things
<paroneayea>the point is
<paroneayea>you do, while hacking
<davexunit>paroneayea: you were talking about doing stuff outside of the source tree
<paroneayea>davexunit: right, which we kind of isolate to in the source tree with mediagoblin's dev setup
<paroneayea>by putting the virtualenv inside that directory
<paroneayea>the point is
<paroneayea>it could go outside
<paroneayea>I'm not saying use virtualenv
<paroneayea>I'm saying, I want a way while in development, to have the program's in-development modules on the PYTHONPATH
<paroneayea>and a way for its scripts too
<davexunit>so runs virtualenv?
<paroneayea>davexunit: no you activeate the virtualenv first
<paroneayea>source bin/activate
<paroneayea>the way we do it in mediagoblin is, you set up the virtualenv like "virtualenv ."
<paroneayea>dumps it right into mediagoblin's checkout. Kind of a mess, but it's all .gitignore'd
<paroneayea>I'm not advocating this, again
<paroneayea>I'm trying to explain so we can think of equivalent functionality
<paroneayea>so, you can do ./bin/python development
<paroneayea>that's the same as source bin/activate && python develop
<paroneayea>so, you can do ./bin/python develop
<paroneayea>but yes, it mutates the paths available in the virtualenv
<davexunit>I'm still confused.
<davexunit>with guix, you can just skip the virtualenv step.
<davexunit>so leaving that out
<paroneayea>but the thing the above gives you
<davexunit>why won't just work?
<davexunit>' develop' specifically
<paroneayea>davexunit: when you run " develop", if you have the virtualenv *activated* (or are using the virtualenv's python), it puts the package you're doing " develop" on on your PYTHONPATH
<paroneayea>because it changes the virtualenv's list of module directories
<paroneayea>to include your project.
<davexunit>so has explicit knowledge of virtualenv?
<paroneayea>davexunit: sorrrrt of, it tries to install to certain paths in your environment variables
<paroneayea>it can do it without a virtualenv
<Steap>paroneayea: so, what happens if you do "guix environment"
<davexunit>ok, so *that* is the code smell.
<Steap>then "python develop" ?
<paroneayea>Steap: right, so it won't know how to do anything right
<paroneayea>because without a virtualenv
<Steap>paroneayea: why is that ?
<Steap>It can still modify the PATH
<paroneayea>it'll install to your system or user pythonpath
<Steap>and the PYTHONPATH
<paroneayea>it doesn't actually modify the PYTHONPATH and PATH env variables
<paroneayea>it modifies this:
<davexunit>I don't understand why it is installing anything
<davexunit>isn't that what ' install' does?
<davexunit>sorry if these are dumb questions, I just know *nothing* about how this all works.
<paroneayea>I'll make it clear
<paroneayea>it has a file with all the path locations.
<paroneayea>now, this is a thing that exists outside of virtualenv, your system python has something similar
<paroneayea>virtualenv just gives you a way to give little isolated versions of these
<Steap>paroneayea: only in /usr/lib, ok
<Steap>paroneayea: so, do you have a piece of code that shows your issue ?
<paroneayea>so virtualenv gives you a way to make an isolated version
<Steap>That might be the simplest approach
<paroneayea>Steap: let me show you the steps I might normally take if I did a mediagoblin checkout
<paroneayea>a little bit abstracted
<paroneayea>git checkout git://mediagoblin/url.git mediagoblin
<paroneayea>cd mediagoblin
<paroneayea>virtualenv .
<taylan>whoops, wrong channel
<paroneayea># this last step puts a bin/ directory with a bin/python and bin/activate and other things
<paroneayea>./bin/python develop
<Steap>don't you source ./bin/activate ?
<paroneayea># this puts the path in lib/blablabla/easy-install.pth, and puts ./bin/gmg
<paroneayea>Steap: right, you can also "source bin/activate"
<paroneayea>but you don't have to
<paroneayea>you can just do ./bin/python
<Steap>using the python executable from the venv is enough ?
<paroneayea>because it has all the paths built-in
<Steap>fun, I thought "activate" was tempering with a lot of env variables
<paroneayea>it does
<Steap>ok ok
<paroneayea>but you can do it without it
<paroneayea>so the alternate verison would be
<paroneayea>source bin/activate && python develop
<paroneayea>so what do we *need* in guix land?
<paroneayea>well, we need a way for ./ to be on the PYTHONPATH, along with any other module directories provided, or whatever
<paroneayea>and we need a way to have scripts the way they're dropped in bin/
<paroneayea>but of course
<paroneayea>we don't have to use setuptools style entry points.
<davexunit>that's outside the purview of guix
<paroneayea>davexunit: not necessarily, because I think we can take a hint from guile and friends.
<paroneayea>a ./pre-install-env might work just fine.
<davexunit>I think the real problem is that tries to write to places that are read-only in guix. it shouldn't do that.
<paroneayea>davexunit: right.
<paroneayea>davexunit: I'm trying to think out loud on how to translate this so you can do things the right way with guix
<paroneayea>the main thing is
<paroneayea>you'll have to duplicate the entry point information in
<paroneayea>since I think reading that is probably not reliable
<paroneayea>but for instance
<paroneayea>you could have a scripts/gmg right?
<paroneayea>and have scripts/ on your PATH with ./pre-install-env
<davexunit>what do you mean by entry point?
<davexunit>yes that could work
<paroneayea>davexunit: let me show you!
<davexunit>but yeah, a script that adds the absolute source directory to PYTHONPATH and PATH should get you where you need to be.
<paroneayea> scroll down to entry_points="""
<paroneayea> entry_points="""\\
<paroneayea> [console_scripts]
<paroneayea> gmg = mediagoblin.gmg_commands:main_cli
<paroneayea>taht basically tells " develop"
<paroneayea>that it wants to generate a script that calls mediagoblin/'s main_cli() method
<davexunit>I don't really know to read that
<davexunit>but your explanation is good enough
<paroneayea>davexunit: ini file embedded in a python script's string ;)
<paroneayea>I'm not saying it's pretty :)
<davexunit>so there's no script file at all.
<davexunit> makes it somehow
<paroneayea>and it drops it in a path.
<paroneayea>however, it's not so bad.
<davexunit>can that directory be configured?
<paroneayea>because all the script does is import some stuff and call it
<paroneayea>davexunit: where things are dropped? yes...
<paroneayea>davexunit: hence my suggestion we generate a script that sets up a virtualenv like thing. But
<davexunit>and where does it make these scripts by default?
<paroneayea>I think your suggestion of doing something ./pre-install-env stuff by default
<paroneayea>davexunit: basically I think it has some heuristics to figure out the right paths, maybe based on some config
<paroneayea>how virtualenv says "put it in my bin/, not on your system path"
<paroneayea>is magic to me
<paroneayea>but it does it
<paroneayea>davexunit: yes, ugh
<davexunit> is awful!!
<paroneayea>davexunit: people are moving to a more declarative setup.cfg but it really doesn't make things simpler
<paroneayea>it just makes it "not python code"
<paroneayea>which has its own problems
<davexunit>that sounds even worse
<paroneayea>yes probably.
<paroneayea>davexunit: luckily these problems are hidden when you just want to *install* things
<davexunit>the issue I have is that doing *development* shouldn't install to my damn global system
<paroneayea>but we also want to make guix into a nice place for developers doing hacking right?
<davexunit>that's an absurd thing for such a dev script to do.
<paroneayea>davexunit: sure, I agree :)
<paroneayea>davexunit: hey man, I didn't make this thing ;)
<davexunit>but I'm sure if the issue was brought up to whoever maintains this tool it will be shrugged off and not fixed.
<paroneayea>davexunit: it's not going to be fixed, not only because it's not considered a problem
<paroneayea>but because the whole python packaging system is such a mess to those who try to hack it even
<paroneayea>due to History(TM)
<paroneayea>that it's considered "the least of their problems" I'm sure
<paroneayea>python's gotten less bad over time but it's mostly because, like many things, new layers have hidden the gross
<paroneayea>and succeed, until they fall over
<davexunit>so, python dev stuff might be a lost cause for now.
<paroneayea>I don't think so.
<paroneayea>for developers who *want* to ship guix stuff
<paroneayea>it's actually not so bad.
<davexunit>I don't see how it can "just work" without asking people to change things.
<paroneayea>I'm just trying to reason it through.
<paroneayea>well the thing is
<paroneayea>davexunit: there's good news.
<paroneayea>this is using setuptools, which is a layer above distutils
<paroneayea>distutils is very low level.
<paroneayea>doesn't include entry points
<paroneayea>doesn't do much
<paroneayea>at a baseline
<paroneayea>all python needs is stuff on its PYTHONPATH
<paroneayea>all that entrypoints stuff is helper stuff.
<paroneayea>those scripts still follow a simple convention
<paroneayea>they're just importing modules and calling methods
<paroneayea>and hey, we can work with that.
<paroneayea>so I think we can just recommend a 2-fold path:
<davexunit>you're the expert, so I'll trust you. :)
<paroneayea> - put the same things you'd normally put in entry_points in scripts/, just some python modules that can run them
<paroneayea>(does /usr/bin/env work in guix?)
<Steap>I hate that craziness so much
<davexunit>paroneayea: guixsd has no /usr
<paroneayea>davexunit: okay so that's trickier :)
<paroneayea>davexunit: the main problem
<davexunit>we consider /usr/bin/env a bad practice
<paroneayea>is how to get that stuff in scripts/ to launch
<paroneayea>without throwing in autoconf
<paroneayea>throwing in autoconf is throwing in the towel as far as python users are concerned I think
<paroneayea>if we can figure out how to launch stuff in scripts/ I can figure out the rest.
<paroneayea>there has to be awy
<paroneayea>a way
<paroneayea>I mean, ./pre-install-env could be smart and launch "./pre-install-env gmg" by rewriting to "python scripts/gmg"
<paroneayea>for instance
<paroneayea>davexunit: what do you think of that approach? some commands pre-install-env knows how to launch with guix's python (or whatever's on $PATH)
<paroneayea>that way we don't need to patch the top shebang
<paroneayea>Steap: your thoughts welcome also
<Steap>paroneayea: honestly, we need a simple dummy project to reproduce the issue
<Steap>then try to figure out exactly what is done by and virtualenv
<Steap>like "read the damn scripts"
<paroneayea>Steap: I could set that up.
<Steap>paroneayea: that'd be nice
<paroneayea>kind of a "python + guix hacking environment best practices experiments" repo
<yrns>Is there a magic environment variable needed to get curl/git working with SSL?
<davexunit>paroneayea: the problem is that autoconf is exactly the tool that solves this problem
<davexunit>that seemingly no other build system can do this is a travesty
<Steap>davexunit: yeah but why would we use autoconf when we cant reinvent the wheel every 2 years ?
<paroneayea>davexunit: sure, but
<paroneayea>davexunit: I need to work within the world we're in
<paroneayea>python devs aren't going to pick up autoconf, they already have a clusterf* of packaging stuff to learn
<paroneayea>and honestly
<paroneayea>we tried autoconf'ing up mediagoblin
<paroneayea>and it made our packaging worse.
<paroneayea>just because you're mixing two really complicated build systems together
<paroneayea>and that doesn't reduce your problems, it just multiplies them
<paroneayea>so we need to add something minimal that works within the world python hackers are in, or give up on them. and being one myself, I can't really give up on them.
<paroneayea>so I could give up on "guix environment as a universal virtualenv", but I think this is probably solvable.
<paroneayea>going to give it a try, anyway :)
<paroneayea>yeah the problem is
<paroneayea>./pre-install-env requires ./
<paroneayea>same problem as the stuff in scripts/
<davexunit>I don't know what the answer will be for python
<davexunit>but it's roughly: generate a script from a template that susbstitutes in the absolute source directory and absolute directory to binaries in shebangs
<paroneayea>davexunit: right
<paroneayea>I'm going to try a couple of things
<paroneayea>one of them which might be "the right way to do it"
<paroneayea>one of them which is a minor heresy :)
<paroneayea>we'll see!
<davexunit>good luck
<paroneayea>*five hours later* oh god I reinvented docker oh noooo
<paroneayea>oh speaking of
<paroneayea>davexunit: I thought of a hilarious idea, are you ready for a really fun heresy?
<paroneayea>or I think it's really fun
<davexunit>yrns: I have SSL_CERT_DIR, SSL_CERT_FILE, and GIT_SSL_CAINFO set
<davexunit>not sure if only the latter is needed for guix
<paroneayea>davexunit: I wonder how hard it would be at this point to build guix-dockerify ;)
<paroneayea>an extension that reads a system profile
<paroneayea>and builds a docker image
<paroneayea>"oh god why would you do it"
<paroneayea>not sure but it struck me that it's likely quite, quite feasible without much more work at this point
<paroneayea>given all else that exists at this point
<davexunit>well it would be easy to write a dockerfile that does the guix binary install
<davexunit>and then builds profiles and whatever else
<yrns>davexunit: Thanks. The last two worked for me - I'll throw in the first for good measure.
<davexunit>yrns: np
<paroneayea>davexunit: Steap: anyway, thanks for brainstorming with me
<davexunit>np, it all makes my head hurt.
<civodul>iyzsong: the new GTK icon handling doesn't work for programs installed in /run/current-system/profile/
<civodul>because that directory is not in the search path or something