<mark_weaver>maybe the daemon is stuck somehow. never had that happen to me though. <Steap>mark_weaver: yeah, I can build stuff <lfam>mark_weaver: You have cut the Gordian knot. Thank you! <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. <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 ;) <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>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` <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>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 <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>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>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 <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>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 <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>export GUIX_PACKAGE_PATH=/path/to/package/dir <xd1le>so i think i need to put it under a subdirectory `my-packages`? <xd1le>okay it works, figured it out. <mark_weaver>paroneayea: thanks, it was great to meet you too! :) <codemac>any tips on what to do about a .a that references libgcc_s.so 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 libgcc_s.so, 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 <codemac>it doesn't exist anywhere, libgcc_s is something gcc adds based on whether or not you use certain functions <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. <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? <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? <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 <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>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 <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. <civodul>lfam: i wanted to do that, but i think some of the Bash headers are missing or something <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. <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 <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>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>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>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 (?) <xd1le>so i did `guix lint bspwm` and that's the only warning. because i want to submit a path to guix <civodul>so the problem here is that the basename of the URL is "0.9.tar.gz" <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". <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>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. <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. ***davi_ is now known as Guest48947
<civodul>where Steap talks about Python goodies <rekado>(is the space in "Bonjour !" correct?) <civodul>yes, that's French typographic conventions <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) ***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 <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>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 <civodul>paroneayea: sorry, should have been: sed -e "s/.*-L\\([^ ]\\+\\)[[:blank:]]\\+-lgcrypt.*/\\1/g" <paroneayea>could be messed up by the line wrap but I'm getting <paroneayea>sed: -e expression #1, char 43: Unmatched ( or \\( <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>what's guix_cv_libgcrypt_libdir this time? <civodul>so you applied the patch and typed "make", right? <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>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 <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 <paroneayea>unrelated: time to package python-pyld for guix. <paroneayea>gonna ship this activitysreams library with a package.scm <davexunit>someone convinced me that this was a better convention <davexunit>ACTION pushes new 'guix environment' exec syntax patches <davexunit>one more issue out of the way for 'guix environment --container' <paroneayea>davexunit: hm, for the "universal virutalenv" purposes, I would like that package to somehow end up on the PYTHONPATH, basically run setup.py develop on the current directory <davexunit>that's beyond the purposes of 'guix environment' I think <davexunit>'guix environment' gets you prerequisite packages <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>in my projects, and guix, I run 'guix environment whatever' <paroneayea>that mutates things outside the current directory <paroneayea>unless you have a virtualenv in-directory, like we do for mediagoblin hacking <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 "setup.py develop" or "setup.py install" may trigger some hooks, eg making some scripts like "gmg" available <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 setup.py develop/install is done.) <paroneayea>davexunit: I suppose a pre-inst-env script could also be written just the same. <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. <civodul>paroneayea: thanks, i'll push the patches <paroneayea>davexunit: a gexp which builds a derivation that's basically a script in the user's path <davexunit>the issue I have with that is that it seems like something that should exist independent of guix. <davexunit>and that script will need to know the absolute path to the source tree <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>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>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 <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>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>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 <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: at some point when around, I'd like to brainstorm about more "guix as virtualenv replacement" stuff with you <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>and not only might that put your current project on the PYTHONPATH <Steap>This is such a terrible idea for deployment, basically as bad as using Docker <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 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 <davexunit>paroneayea: you were talking about setup.py 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>I'm saying, I want a way while in development, to have the program's in-development modules on the PYTHONPATH <paroneayea>davexunit: no you activeate the virtualenv first <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 trying to explain so we can think of equivalent functionality <paroneayea>so, you can do ./bin/python setup.py development <paroneayea>that's the same as source bin/activate && python setup.py develop <paroneayea>but yes, it mutates the paths available in the virtualenv <davexunit>with guix, you can just skip the virtualenv step. <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 <davexunit>so setup.py has explicit knowledge of virtualenv? <paroneayea>davexunit: sorrrrt of, it tries to install to certain paths in your environment variables <Steap>paroneayea: so, what happens if you do "guix environment" <Steap>then "python setup.py develop" ? <paroneayea>Steap: right, so it won't know how to do anything right <Steap>It can still modify the PATH <paroneayea>it doesn't actually modify the PYTHONPATH and PATH env variables <davexunit>I don't understand why it is installing anything <davexunit>sorry if these are dumb questions, I just know *nothing* about how this all works. <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>git checkout git://mediagoblin/url.git mediagoblin <paroneayea># this last step puts a bin/ directory with a bin/python and bin/activate and other things <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" <Steap>using the python executable from the venv is enough ? <Steap>fun, I thought "activate" was tempering with a lot of env variables <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>we don't have to use setuptools style entry points. <paroneayea>davexunit: not necessarily, because I think we can take a hint from guile and friends. <davexunit>I think the real problem is that setup.py tries to write to places that are read-only in guix. it shouldn't do that. <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>you'll have to duplicate the entry point information in setup.py <paroneayea>since I think reading that is probably not reliable <paroneayea>and have scripts/ on your PATH with ./pre-install-env <davexunit>but yeah, a script that adds the absolute source directory to PYTHONPATH and PATH should get you where you need to be. <paroneayea>that it wants to generate a script that calls mediagoblin/gmg_commands.py's main_cli() method <paroneayea>davexunit: ini file embedded in a python script's string ;) <paroneayea>because all the script does is import some stuff and call it <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>davexunit: people are moving to a more declarative setup.cfg but it really doesn't make things simpler <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. <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>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 <davexunit>so, python dev stuff might be a lost cause for now. <davexunit>I don't see how it can "just work" without asking people to change things. <paroneayea>this is using setuptools, which is a layer above distutils <paroneayea>they're just importing modules and calling methods <paroneayea> - put the same things you'd normally put in entry_points in scripts/, just some python modules that can run them <Steap>I hate that setup.py craziness so much <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>I mean, ./pre-install-env could be smart and launch "./pre-install-env gmg" by rewriting to "python scripts/gmg" <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) <Steap>paroneayea: honestly, we need a simple dummy project to reproduce the issue <Steap>then try to figure out exactly what is done by setup.py and virtualenv <Steap>like "read the damn scripts" <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: 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>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. <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>one of them which might be "the right way to do it" <paroneayea>*five hours later* oh god I reinvented docker oh noooo <paroneayea>davexunit: I thought of a hilarious idea, are you ready for a really fun heresy? <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>not sure but it struck me that it's likely quite, quite feasible without much more work at this point <davexunit>well it would be easy to write a dockerfile that does the guix binary install <yrns>davexunit: Thanks. The last two worked for me - I'll throw in the first for good measure. <paroneayea>davexunit: Steap: anyway, thanks for brainstorming with me <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