<Apteryx_>I've found a bug with our Python where the "user site package" appears following the "site package", which causes the behavior of "pip install --user" behavior to be slightly broken (there's no user override possibily over system installed libraries).
<Apteryx_>I'm trying to understand where/how this discrepancy compared to usual Python comes to life; I know that the problem is caused by "sys.path" (PYTHONPATH) containing the "site package" locations before even running the main() of site.py.
<Apteryx_>In an environment, the system site-package location is put before the user site-package in PYTHONPATH. Usually it must come after so that a user can override any system installed package. Not sure why this only manifests in environment vs regular user profile...
<Apteryx_>rekado: I see! Thanks for the explanation. I'm starting to see clearly.
<Apteryx_>In an environment, there this "profile" entry which gets prepended at the beginning of PYTHONPATH, which explains the different behavior: '/gnu/store/ar7k7ds90ikxv40a6lif6jv2g39l7mls-profile/lib/python3.5/site-packages'.
<Apteryx_>Which piece of code would take care of creating this temporary "profile" when using a guix environment?
<rekado>Apteryx_: the entry point is guix/scripts/environment.scm
<Apteryx_>rekado: OK! Thanks :) This will keep me busy for a couple hours tomorrow.
<ng0>But I think their git can be used in this case
<roelj>Running: `./pre-inst-env guix environment --container guix --pure coreutils' and then ./bootstrap; ./configure; in a fresh guix git checkout results in: `configure: error: C compiler cannot create executables'. What am I missing here?
<roelj>In config.log I find: ld-wrapper: error: attempt to use impure library ...
<wingo>roelj: a c compiler? doesn't --pure mean that you don't have anything?
<wingo>if you need to get around that issue for whatever reason you might try GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yep
<roelj>wingo: Well, it's a container anyway with the tools needed to build guix. Wow, the GUIX_LD_WRAPPER_ALLOW_IMPURITIES=yep works. Isn't it bad though?
<ng0>I'm not sure about this build... What if I have found a bug in the substitute function or something like this? Well it would be more like a bug in this bloated software (pike), but I'm not doing anything wrong
<roelj>ng0: To select for '$srcdir' you'll need to do '\\\\$srcdir' in the substitute*.
<rekado>and with some macro action I think you could hide the (assoc-ref environment ...) stuff to just bind all environment members in the scope of the gexp
<roelj>rekado: That's so weird.. If I do: (string-append #$samtools "/bin/samtools"), it results in a gexp containing: #<gexp ... (string-append #<gexp-input #<package samtools#1.3.1 gnu/packages/bioinformatics.scm:4134 *hash*> "/bin/samtools") ...
<roelj>rekado: I'd love to see that macro action.. ;) I'll work on that
<civodul>roelj: don't use 'package-output', it's often a bad idea :-)
<civodul>so yeah, just #~(system* #$(file-append samtools "/bin/foo") "blah")
<roelj>Is there a build log available for something you (build-derivations ...)?
<roelj>Or another way I can get the script after the gexp has been resolved to its final execution form?
<civodul>roelj: print the .drv file name, open it, and then open the "-builder" file it refers to
<adfeno>For me, it being on GitHub, means that free/libre software activists will either have to convince GitHub to free/liberate their JS, or have to send patches and issues by email instead of through GitHub.
<davexunit>I think you can use the notabug project page instead?
<davexunit>but then issues/patches are divided between two sites
<cbaines>Does anyone have any tips on debugging guix system container? Sometimes when my code has bugs, guix system container gives me a cryptic error (Unbound variable in the system definition), and everytime I have had this, getting past it has involved fixing something completely seperate...
<civodul>cbaines: does 'guix system build' give you that same error?
<civodul>IOW, is it a "host-side" or a run-time issue?
<ng0>I think i figured out how fedora fixes mozjs-38
<cbaines>I've converted the system to a module so I can load it with use-modules from a REPL, and I can see from Guile that there are some unrelated warnings elsewhere, and I bet the actual problem I'm having is to do with one of them
<cbaines>I'm going to fix them, and then see if that makes the error go away
<civodul>cbaines: you could also have troubles if your modules have circular references
<civodul>but yeah, you should investigate from the REPL
<cbaines>Is there an easy way to check for circular references, as I think I've ran in to that problem before?
<davexunit>not that I know of, but they are easy to avoid.
<davexunit>ld-wrapper is adding flags, but I want to use regular ol' ld
<davexunit>I even used package-with-explicit to remove ld-wrapper from %final-inputs and it still didn't work
<davexunit>sneek: later tell civodul I tried removing ld-wrapper from a build using package-with-explicit-inputs but the resulting shared library still has hardcoded reference to glibc libgcc. what's up with that?