IRC channel logs
2024-09-23.log
back to list of logs
<PotentialUser-11>Hi guix! Right now I'm installing guix system using lightweight-desktop example config. I noticed that during the install process it downloaded some, as I think, strange packages like python-jupiter and python-numpy. Can anyone explain why this happened if i haven't added anything python related to the config? <jaft_r>PotentialUser-11: I'm not familiar with the config. but my guess would be that something in the config. uses those as dependencies (or a dependency of something in the config. has these as dependencies, etc.). <meaty>How can I define a simple service to start a daemon on login? <jmes>meaty: you'll probably want to use Guix Home to start a shepherd service which manages your daemon. In your home config, add to your services list something like this: https://bpa.st/5SV66 <jmes>Great if you figured it out already :) <jmes>you may want to check the docs to see if you want a different type of constructor <jmes>At a glance it looks good to put in your operating-system definition. It would start at boot not login, which is probably what you want here for fan controls, I guess. <jmes>meaty: np, let me know if it works out for ya <mange>Roughly, yes. I manage my systems using guix deploy and the managed-host-environment-type, and the first part of that post looks like what I have. <Rutherther>Yesterday someone mentioned the digital ocean solution would need fixing to work again <taeaad>Rutherther: Thanks, I don't use Digital Ocean, mostly AWS. <taeaad>The %store-monad part tickles my interest, though it might have to tickle more vigorously to maintain my attention. <taeaad>I am not sure what I think of the result of category theory influencing computer science directly. When it influenced numerical ecology in the 1970s and later the result was positive but few people still know about the connection. <taeaad>(If anyone wants a reference: "Multivariate Ecology: The French Way" by Susan Holmes.) <mange>The %store-monad bit in that post is just a reflection of its use in Guix more broadly. It's not specifically related to "guix deploy". <lynn_sh>hello geeks, i have an issue that is a bit perplexing: `env|grep LC` gives no output. /run/current-system/locale/ has two versions in it, both populated. locale -a gives what i would expect. any ideas? <mange>lynn_sh: I also have empty output for "env | grep LC". Is that a problem? I have LANG set, at least. <lynn_sh>i thought it might be, when i launch nyxt it tells me locale is not supported, falling back on default. then it gives a memory error, so i thought it may be related. <lynn_sh>im trying to hunt down why nyxt cannot launch. <mange>You've installed nyxt through Guix? <lynn_sh>if i run it a few times eventually i get "<WARN> [08:29:03] Warning: Error on GI-GTK thread: Unhandled memory fault at #x8." <mange>I'm seeing "Locale not supported by C library." when I start it, but no crash. <mange>Has nyxt worked for you previously? <lynn_sh>a few weeks ago. i found a similar issue in the NixOS forums, WEBKIT_DISABLE_COMPOSITING_MODE=1 nyxt fixes it. <lynn_sh>apparently there is an issue in webkit, and i probably did a guix pull and updated to the version with that problem hence the issue arising. <mange>You could try rolling your profile back to the previous version, which could at least get it working for now (albeit with a slightly older version). <lynn_sh>LC_ALL="en_US.UTF8" nyxt actually fixes it as well. is there a reason guix doesn't set LC_ALL? <taeaad>I wonder if it is a Guix issue, I had similar issues on Ubuntu too. <lynn_sh>i can just set it in my home configuration for now with a note <mange>Is there a reason why Guix should set LC_ALL? I'm not familiar with the LC_ variables. <lynn_sh>im not sure guix is in charge of that or if desktop portal is, but guix does set my locale so i would imagine it's related? <taeaad>I usually don't send LC_ALL because I often want LC_COLLATE to be C.UTF-8. <mange>Based on my quick reading, it sounds like LANG is meant to be the "default", and the LC_ variables are meant to be used to override things. LC_ALL overrides all the other LC_ variables, so it seems heavy-handed for the distribution to set it. <lynn_sh>it's possible i should be setting a different one tbh since LC_ALL is an override <lynn_sh>the LC_* override working seems to be a dud anyways, it just crashes less often now. <mange>You could also try using "guix install nyxt --with-branch=nyxt=master" (or equivalent) to build from master and see if that works. That will compile Nyxt locally, though, so it could take some time. <lynn_sh>is it possible to run that in a shell? <lynn_sh>i don't want to overlap my home nyxt and user nyxt just incase it resolves the home one first. <mange>Yeah, "guix shell nyxt --with-branch=nyxt=master" also works (and is what I meant by "or equivalent"). <taeaad>lynn_sh: How does Nyxt compare to Qutebrowser? <lynn_sh>it's all configurable in common lisp which is nice and homey feeling <lynn_sh>that's about the only reason im trying to use it over qute <lynn_sh>system-crafters did a video on it but i don't think he gelled with it much. <lynn_sh>i think it's because webkitgtk-for-gtk3 is on 2.44.1, it was patched in 2.44.3 <mange>"guix shell nyxt --with-branch=nyxt=master --with-version=webkitgtk-for-gtk3=2.44.3"? :P <mange>I imagine that would be a much more substantial compile step. <lynn_sh>it seems to get confused since webkitgtk-for-gtk3 inherits webkitgtk <lynn_sh>is there a "with-branch" but for tags? <amano>Can anyone show me the output of guix shell --search-path some-python-package? <mange>The options are documented in the manual (see: (guix) Package Transformation Options). Using --with-commit should work for a tag. <lynn_sh>ty. i was reading the manual but wasn't sure if with commit would work! <mange>"guix shell --search-path python-pygments" => guix shell: error: search-path: unrecognized option <mange>"guix shell --search-paths python-pygments" => export PATH="/gnu/store/qh47cygrih48z598lghwymgyyabjh8y8-profile/bin${PATH:+:}$PATH" <mange>If anyone asks, I'm a bot. :P <amano>I want a python package that has python dependencies. <lynn_sh>you may have luck skimming python-xyz for a package that meets your critera <amano>It's weird. On gentoo linux, dev-python/pygments has python dependencies. <amano>I thought guix shell --search-paths was supposed to give me python search paths. <lynn_sh>ok, guix shell --pure nyxt --with-commit=nyxt=3.117 --with-version=webkitgtk=2.44.3 works. should i make a patch for webkitgtk? <lynn_sh>amano try adding python to your shell <amano>lynn_sh: I'm on gentoo linux now. <Rutherther>You need to include python as well as that has the search path definition <amano>If I was on gnu guix, I wouldn't be asking questions. <lynn_sh>amano ok. if you want the search paths to have linking paths, you need to add your compiler/linker. so add clang, zig, python, etc. <mange>a) You can install Guix as a package manager on Gentoo and still run these commands. b) What is the question you're actually wanting to answer here? <mange>I feel like "what is the output of this command" isn't the root question, right? <amano>I want to port janet language to nix and guix. <amano>To port janet to nix and guix, I need to know whether search paths include the build directory for a package that's going to be installed. <amano>Without janet-build-system, I can't create janet packages. <amano>Does guix shell include the current directory in search paths? <amano>Then, janet needs to account for that. <lynn_sh>(native-search-paths) is probably going to be helpful for you to look at <mange>But that's not "the build directory for a package that's going to be installed". The current directory is the directory that "guix shell" is run in. <amano>I guess guix doesn't put the package build directory in search paths. <Rutherther>It includes only paths under the profile built for the shell <mange>I still feel like I'm not clear on what you're trying to do. <lynn_sh>if you need to build a janet package and janet is in your inputs, then janet needs to have a native-search-path definition <lynn_sh>right now guix shell janet --search-paths has nothing except PATH. <amano>I asked janet maintainer to support multiple paths in JANET_PATH. He added multiple path support. <amano>Does nix also use search paths? <lynn_sh>just real quick, for some of the regulars here, should i add a patch to bump webkitgtk to the minor version that fixes nyxt? or should i leave that to a regular maintainer? <mange>Sending a patch can't hurt. :) <amano>Does guix put the package build directory in search paths? <mange>Guix doesn't do anything, by default. A package can declare directories that should be added to search paths when it's installed in a profile (see the manual for more details: (guix) Search Paths). <lynn_sh>when writing patches do you pull down the repo or is there a local instance already on my system i should be editing? <lynn_sh>right now i just pull the repo and do guix build -L. -e '(@@(gnu ...)' <amano>It seems guix demands packages instead of guix shell scripts. <amano>Search paths are inefficient, but compiled packages don't need to search paths. <mange>Search paths are only needed for discovery. The compiled program needn't rely on search paths. For instance, packages that compile C might needs things in their C_INCLUDE_PATH, but the compile program doesn't read that environment variable. <amano>mange: What about python path? <mange>Like, what is the question about python path? <amano>Python doesn't support compilation into one binary executable. <amano>It will require python search paths always. <amano>Plain search paths are inefficient. <amano>Search paths that map package to a path are efficient, but no programming language hasn't been written to support that. <mange>When you install python and dependencies into a profile, the search path contains the profile's /lib/python*/site-packages directory, which is a bunch of symlinks with things in the right places. <futurile>lynn_sh: pull down the guix repo. Start a guix shell, then use the ./pre-inst-env script to run guix from the repo's directory <mange>In another distribution, this would be in /usr/lib/python*/site-packages, or whatever, but that's not an option in Guix. <lynn_sh>futurile ty. i was running that in my emacs automatically but forgot to run it in my shell <amano>mange: So, that means guix can put janet modules in a profile directory? <mange>So the search paths mechanism points to a single directory in this case, while allowing different profiles to be layered and all be loaded by python. <amano>Hmm, I think PYTHONPATH for python-pyqt in guix shell was a list of /gnu/store directories.... <lynn_sh>tyty. i did my hacky way to build it right now but will do this in the future. right now webkit is taking a very, very long time. lol. <lynn_sh>in the future i think i should do this on my dekstop. <amano>mange: python-pyqt's search paths aren't a profile directory. <lynn_sh>hopefully the patch won't take that long to get merged.. i want nyxt to run ;_; <mange>"guix shell python python-pyqt --search-paths" => export GUIX_PYTHONPATH="/gnu/store/c5li40mk7939r3ckpza8379vb2jqw7k5-profile/lib/python3.10/site-packages${GUIX_PYTHONPATH:+:}$GUIX_PYTHONPATH" <nckx>lynn_sh: To elaborate on mange's highly correct answer: don't, generally, wait for 'package maintainers' in Guix. There's no package ownership like in some other distributions, only reviewer teams, and no such thing as unwelcome constructive patches. <amano>Does that mean janet's search paths will just point to one profile directory as well? <lynn_sh>nckx ty, i am used to ownership of a different structure. ill keep that in mind :) <amano>When someone else did it, python-pyqt's GUIX_PYTHONPATH had 18 directories. <amano>When mange does it, it has one directory. <mange>I don't know what to tell you. :) <nckx>Now, your patches may take too long to review & merge, but that's a separate problem and not at all a hint that you stepped on any toes. <lynn_sh>amano i think earlier you said you didn't have guix installed.. it may help to install guix <nckx>amano: Then they used a different command or were not talking about the same thing. It's deterministic. <mange>But also, you're talking about inefficiencies in something that doesn't currently exist (Janet packaging). My usual strategy for things is "make it work, then make it fast". Maybe start by making it work, then we can help you make it fast. :) <amano>> When there are several lib/python/3.9/site-packages—this is the case in package build environments—they are all added to GUIX_PYTHONPATH, separated by colons (:). <nckx>You don't have Guix installed? Asking people here to run guix for you to answer basic 'I wonder what...' questions doesn't sound like an efficient use of your own time. <nckx>Certainly not of theirs. <amano>I guess I will install guix on gentoo linux. <amano>So, GUIX_PYTHONPATH contains multiple search paths in package build environments, and it contains one profile directory in runtime environment? <nckx>Most of us learn by playing. This applies equally to adults. <amano>Is it safe to assume that JANET_PATH will be multiple paths in package build environments and one path in runtime environment? <amano>One profile directory in runtime environment. <nckx>amano: GUIX_PYTHONPATH *is* a search path, it contains 0 or more directories. It contains the same directories in the build environment as it does at 'run time' *if* your run time contains all the same packages. <nckx>It does not get collapsed into a single directory at arbitrary times, no. <mange>But also, it will work the way you make it work. The maven-build-system, for instance, makes a tree of files matching the Maven repository format so maven can find what it's looking for. <lynn_sh>JANET_PATH isn't defined from what i can tell, anywhere in guix. i think you would need to define it. <amano>JANET_PATH just gained support for a colon-separated list of paths. <amano>I guess this is necessary for build. <mange>You're asking about a hypothetical build system and what it will do, when the build system is code you write that can do whatever you want it to. If you need a particular directory structure under a single directory then you can make Guix do that. <nckx>It's more convenient for sure. <amano>Can I install every janet library in one profile directory? <nckx>A 'path' that can contain only one directory is hardly a 'path'. <futurile>taeaad: I haven't seen anyone using it recently. I keep meaning to look at it. <futurile>taeaad: maybe some of the academic users use it, as the project was driven by some engineers that work in that environment <nckx>amano: Generally, the only thing that breaks doing so is propagation. If the Janet packages in Guix (or your own) manage to avoid propagation, chances are high. <nckx>It's when installing (=bringing into a profile) one package brings a dependency along with it. So installing A also installs B. <nckx>So similar to most package managers including portage. <amano>Portage doesn't have propagation. <futurile>taeaad: you could email guix-user/devel or the group to see what's happening with it. It looked interesting <amano>nckx: Does janet need to support multiple module paths to support guix? <amano>I don't understand how propagation breaks one profile directory for one language's modules. <nckx>We were talking about a rather hypothetical case of installing all Janet packages into one profile, and while it's not guaranteed to brake, if there exist (say) a janet-gtk@4 and janet-gtk@3 library that both propagate their respective gtk libraries, that might clash. <nckx>Guix has no concept of 'slots' because a purely functional package manager shouldn't need it, but propagation breaks the functional model somewhat. <nckx>Or at least nopes out of it at the most inconvenient of times. <amano>Hmm, explicitly installed python modules and their propagated inputs go into profile? <amano>Then, JANET_PATH cannot be one directory. <amano>It will have to contain multiple directories. <amano>Propagated inputs shouldn't be necessary with proper support for multiple paths in programming languages. <amano>C language doesn't support multiple header paths? <nckx>ACTION away just means I'm AFK and not ignoring you and also wat yes of course C does support it but also no it's not a hard requirement but also removing propagation would be a big project and also really away for now, bye. ;-) <amano>I think propagated inputs prevent me from installing multiple version of the same package. <futurile>amano: a propagated input is added to the users profile. It's for dynamic languages like Python/Perl that can't store things that are needed at runtime as references. As it adds packages to the users profile, if you have two packages that conflict then you can't install them. That's why propagated inputs are 'not liked'. <amano>futurile: needed at runtime for references? <amano>You mean path information is not recorded into the applications? <futurile>amano: languages like Perl/Python use need paths at runtime to find their modules right. The famous PYTHONPATH, to find site-packages. So all that propagated-inputs is doing is adding paths to Store locations where those modules can be found. Propagated-inputs is all about the runtime <amano>In theory, PYTHONPATH can be a list of directories in /gnu/store. <amano>But, a list of directories is inefficient during runtime. <futurile>amano: I'm not really debating whether it's good or bad. I'm just pointing you to where you can find out info for yourself. <futurile>amano: it's not a loved part of the system. But it's what we have :-) <amano>For python to support guix properly, it will have to support compilation of python applications. <amano>I proposed such a change for including resource paths found in JANET_PATH in the compiled janet executables. <amano>If resource paths are included in compiled janet executables, janet shouldn't require propagated inputs for reading resource files. <futurile>amano: generally, anything that is 'compiled' using a C compiler will use references. <amano>Meaning no propagated inputs? <amano>All module paths should be included in the compiled executable to eliminate propagated inputs. <AwesomeAdam54321>amano: Note that that only applies to executables that have a fixed set of modules <amano>If it's not fixed, then propagated inputs are necessary again? <amano>By the way, if I run guix shell, are the necessary dependencies automatically installed in profile? <amano>Propagated inputs require a profile, and guix shell has to honor propagated inputs. <amano>I think interpreted languages can support multiple paths... well... <amano>Can a build system automatically add hidden propagated inputs to packages? <amano>Does guix add the package build destination in /gnu/store to search paths? <AwesomeAdam54321>amano: There are build systems that automatically add build inputs, so it should possible for a build system to add propagated inputs <AwesomeAdam54321>It's better for propagated inputs to be explicitly specified in packages that need it <amano>Are inputs run-time dependencies? Are native inputs build-time dependencies? <amano>run-time dependencies must not be deleted by garbage collector. <AwesomeAdam54321>Native inputs are build-time dependencies, inputs are build dependencies, propagated inputs are runtime dependencies <AwesomeAdam54321>Since propagated inputs are specified in the package definition, the garbage collector won't delete it until no package profiles use that package <amano>How can I ensure that certain inputs are not deleted by garbage collector? <amano>Are all "inputs" protected from gc? <Kabouik>nckx: regarding my GLIBC_2.38 not found error, does that make sense to you? https://0x0.st/XYcJ.txt libxfce4util is in my /gnu/store but not found in my profile. <AwesomeAdam54321>Are all "inputs" protected from gc? <- Yes, for as long as there are packages installed that use those inputs <amano>AwesomeAdam54321: What counts as usage? <amano>Dynamic link? Or, the mere fact that something uses it as input? <amano>I mean the fact that something specifies it as one of inputs. <lynn_sh>hey geeks, if guix build <package> --check fails what is the way to investigate further? <futurile>lynn_sh: guix build <package> works; does guix build --source <package> work? <futurile>lynn_sh: then try the source one with the --check; and then the plain build with --check. That should tell you if it's the source or the package build that's not reproducible <futurile>ok, so your source is downloading repeatedly correctly. <lynn_sh>im still trying to pinpoint the issue it's running into for a memory error to occur on boot <futurile>OK. I don't know what that is. But most commonly it's a timestamp from what I understand. <lynn_sh>so the --check is not something that necessarily means something is wrong? <futurile>I don't think there's any posts or anything in the manual about this. <lynn_sh>sorry about the complicated questioning. i'd prefer to not have to flatpak it if possible so im really trying to figure this out <futurile>no the package could be building fine. It's just that in the Makefile or in a function somewhere there'll be something that is changing when the package is rebuilt (timestamps are most common). Someone should have fixed it for packages in the Guix repo - but they're hard to track down. <dariqq>lynn_sh: maybe --no-grafts and if there is still a difference try to investigate with something like diffoscope on the outputs? <lynn_sh>--no-grafts still crashes and still isn't reproducable <futurile>you're getting a memory error on boot - have you checked your hard drive filesystem? <lynn_sh>and it's been reported that webkitgtk 2.44.3 fixes it, but it also works in a guix shell nyxt --pure, so im trying to figure out the issue if it works in that env. <futurile>oh so you have to start it with: WEBKIT_DISABLE_COMPOSITING_MODE=1 nyxt and then it doesn't crash? <lynn_sh>or i can do `guix shell --pure nyxt` then open it and it works <amano>Are all "inputs" of an installed package protected from gc? <futurile>lynn_sh: weird that guix shell --pure works. Are you running a full 'guix system' or 'guix' as a package manager on top of another distribution? <lynn_sh>i am running guix system with guix home as well <lynn_sh>the difference in output between guix shell --pure and regular package is the guix shell --pure doesn't give Locale errors <futurile>the fastest way would be to use a shell alias so you just start with that env variable all the time <lynn_sh>that's what i may end up doing. i just really wanted to solve the issue <lynn_sh>nyxt is not an uncommon browser for guix users, so i can't be the only one running into this, but i see no chatter of it. <futurile>3507 seems to indicate a problem with the package, since the dev is right that if the flatpak one works then it has to be something witht he package. <futurile>Nothing on issues.guix.gnu.org about nyxt <futurile>amano: I think at this point you're going around in circles. I suggest you read the blog post I gave you, and the manual on package inputss. That's going to make it a lot clearer. <futurile>amano: awesome adam already answered your question. But the problem is you have to understand how inputs->references work and then it will be clear how these are translated into a users environment (profiles/envs) and consequently why the GC doesn't delete things that users have. <nckx>'Fanyone needs an excuse to yell "I'm not playing video games, ma, I'm defending freedom!": https://issues.guix.gnu.org/73435 is in need of hard observations, not conjecture, and I'm not able to provide them right now. <futurile>lynn_sh: I guess if there's nothing in the guix issues DB, you could try asking on the user mailing list. But yeah, you might have to use the flatpak OR create a shell script to launch nxyt in a shell env with that environment variable set <nckx>Also, you get to blorp demons. <lynn_sh>futurile: i added the override to my env variables for now. that gets me up and going. im going to revisit it later i think, it has taken a lot of energy so far. thanks for the help. <futurile>lynn_sh: makes sense, no point getting 'stuck' for now if there's a temporary workaround <amano>At least, it's good to know that guix supports programming languages that don't support multiple module paths. <amano>as long as you are willing to give up purely functional packages. <amano>Even for programming languages that support multiple module paths, propagated inputs seem to be used if they don't add module file paths to compiled executables. <Rutherther>why would you have to give up purely functional packages? <amano>Rutherther: propagated inputs are inserted into profile where there can be clashes between different versions of the same package. <nckx>There's nothing that Guix fundamentally cannot support, even without propagation. It's just a convenient crutch. <mange>What do you mean by "purely functional", as applied to a package? <amano>Raku language avoids clashes between different versions of the same package because raku can differentiate between different versions of the same package on any linux distro. <mange>Propagated inputs do not violate my definition of "purely functional" for packages, so I don't quite know what you mean. <nckx>Rutherther: I said something to that effect, for the record. If you take issue, take it with me. When I return that is. <amano>Janet doesn't natively support the notion of versioning, but janet packages have versions. <amano>A-1.1 and A-2.0 are installed as propagated inputs, they will clash with each other in profile <amano>Different versions of a purely functional package should not clash with each other. <amano>Propagated inputs create a global space where different versions of a package can clash with each other. <mange>I don't agree. It just means that constructing a profile from packages is not a total function. It's still a reproducible process, where the same inputs leads to the same outputs. <mange>It's not global, it's just that the values conflict *when combined by the profile construction function*. <amano>What I mean is that propagated inputs can lose the ability to install different version of a package. <amano>I'm aware that there can be multiple profiles. <mange>Propagated inputs restrict the space of valid inputs to profile construction, but they don't completely break the functional paradigm. <amano>But, within a profile, you may not be able to have different versions of a package. <amano>For raku language, propagated inputs are fine because different versions of a package in the same profile don't clash with each other. <amano>For janet language, propagated inputs in the same profile will lead to clashes... <Rutherther>you can have multiple in one profile if you wrap it and expose only binaries or other stuff you need. You just have to make sure to take care to not include two packages with the same files <amano>Are search paths erased in runtime environment? <amano>In guix shell and build environment, search paths would be available. <mange>klm`: I think computed-file has to write to #$output. I think you want mixed-text-file instead? <amano>Let's say that I installed a python application. Guix doesn't make search paths available for the application, right? <klm`>mange: thank you! that did the trick :-) I still don't understand the differences between computed-file and mixed-text-file though. <amano>In guix shell and during package build, search paths would be available for a python application or a python library. <mange>computed-file: a gexp that creates a file in #$output with whatever contents you want (constructed by any means). mixed-text-file: a gexp that creates a file in #$output by writing the equivalent of (string-append ...) with the gexp arguments you give it. <Rutherther>amano: python applications are wrapped, so you don't need nor have a separate search path in the profile / shell, yeah <amano>If module paths aren't etched into application executable, propagated inputs are going to be necessary, right? <amano>Rutherther: You mean guix etches search paths into the wrapped executables, right? <Rutherther>yes, it makes a script with exporting guix_pythonpath <amano>Does python not support multiple paths already? <amano>Why is guix_pythonpath needed? <amano>It seems python packages just specify python dependencies as propagated inputs. <amano>That means python applications doesn't need to specify multiple paths. <Rutherther>of course it does. The applications need to be wrapped to work outside of profiles <amano>Rutherther: Can you show me one python application, then? <dariqq>amano: e.g. power-profiles-daemon: powerprofilesctl is just a python script that needs some python dependencies. To avoid having to propagate python and the python dependencies powerprofilesctl is wrapped with GUIX_PYTHONPATH <amano>It's weird. Some python applications propagate python dependencies. Some don't. <amano>dariqq: Can you paste the content of powerprofilesctl? <Rutherther>All the ones that can be used as python modules need to propagate their inputs currently. Since if you then include it in profile you expect to be able to import it, and that requires the dependencies as well <amano>In theory, you can just put multiple paths in PYTHONPATH. <Rutherther>Thats not the problem. The problem is identifying what paths to put there <amano>Where is this problem documented? <Rutherther>I am not sure it is. It doesnt seem like something would require separate documentation <mange>The manual talks about propagated inputs in "(guix) package Reference", but there's not much written about it. <amano>Ah, you have to write the python wrappers manually? That's why you usually just propagate python dependencies? <amano>If the python wrappers can be written automatically by python-build-system, then we won't need to propagate python dependencies? <mange>No, because of libraries. You can't wrap a library to change it's search path locally, it has to be set for the whole process. <amano>Guix doesn't know how to find (transitive) python dependencies? <mange>The conflicts that propagated inputs cause are, in some sense, real. Like, in Python, you can't load two versions of Flask into the same process (without hacks), so if you had two python libraries as dependencies which declare different versions of Flask, you're stuck. <mange>This is where dependency resolution algorithms usually come in, but Guix is a purely functional package manager, so you shouldn't magically have your declared dependencies changed for different versions, so instead we say that profile construction is a partial function which can fail. <amano>I thought python dependencies were propagated for efficiency. <amano>If compilation step doesn't eliminate search paths, search paths would be inefficient. <amano>Python doesn't let you compile a python application into one executable. <amano>In theory, it can compile python modules into one executable that has python VM and python byte codes. <mange>We're back to where we started. :) <amano>Propagation eliminates search paths which are inefficient during runtime. <mange>Propagation is not about eliminating search paths. That is not its purpose. <amano>It can serve any purpose I want. <mange>I am certain that looking things up on search paths is one of the most efficient parts of Python. :) <amano>Not efficient if there are 200,000 search paths. <amano>Imagine a python application that has 200,000 transitive dependencies. <mange>I really don't know what you're looking for in this conversation. <mange>I feel like we have approached this from a lot of angles, and you don't seem to be happy with the way Guix works. <amano>mange: I am not happy with the way I haven't understood how guix handles python. <amano>Your argument seems to be that only propagated inputs can be picked up by guix and added to GUIX_PYTHONPATH. <mange>That is not my argument. I am not making an argument. <amano>Why does guix propagate python dependencies again? <mange>I am trying to describe to you how Guix works, and why it works that way. I'm not saying it's the only way it could work, nor am I defending any decisions. <mange>Propagated dependencies are other packages which are installed into the profile alongside a package. If X propagates Y, then installing X into a package also installs Y into that package. <mange>That is all. They are nothing beyond that. <amano> https://www.futurile.net/2024/03/29/guix-package-structure-inputs/ says Not all languages have the ability to record and use an ELF runtime path - many of the dynamic languages like Guile, Perl and Python fall into this category. This means that Guix can't automatically know about all the libraries that are required at runtime. To cover these packages there is the propagated-inputs. <amano>It seems propagated inputs are used for efficiency of seeking modules. <mange>Why do you think that? Has anybody said that except you? <mange>Propagated inputs are not about efficiency. <amano>That article seems to say t hat. <mange>Where does the article say that? <amano>"Not all languages have the ability to record and use an ELF runtime path - many of the dynamic languages like Guile, Perl and Python fall into this category. This means that Guix can't automatically know about all the libraries that are required at runtime. To cover these packages there is the propagated-inputs" <mange>What in that makes you think "efficiency"? <amano>In theory, you just make all python dependencies add themselves to search paths through python-build-system, right? But, guix developers seem to want to avoid using search paths at runtime. <mange>How can a python dependency add itself to a search path when it is not in the profile? <amano>The only conclusion I can infer from that article is guix maintainers don't want to use a huge list of search paths at runtime. <amano>mange: I didn't know search paths were reserved for things in profile? <amano>Things in profile need only one search path. Search path"s" can refer to /gnu/store. <mange>If I install python-flask to my profile, how can Guix know to also make python-jinja2 (a dependency) available as well? <amano>A package can export search path environment variable. <amano>A build system can make a pacakge expoert search path. <mange>How can we ensure that they don't conflict, if a different package has a different version of python-jinja2 as its dependency? <amano>mange: propagated inputs don't answer that question. <amano>Python has to solve that question. <mange>Propagated inputs fail to build the profile. How would you prefer Guix to resolve the problem now (given Python does not)? <amano>Raku answers that question with its own functional packages. <amano>mange: You don't use different versions of the same python package in one application. Simple. <amano>Python hasn't been designed to use diffrent versions of a python library in one application. <amano>Guix can't fix that for python. <mange>Propagated inputs enforce that constraint. Would you rather we hide the dependency and build a broken profile? <amano>Raku can use different versions of a raku library in one application. <amano>mange: The problem with propagated inputs is that it prohibits different applications from requiring different versions of the same library. <amano>B depends on A-1.1, and C depends on A-2.0. A-1.1 and A-2.0 are incompatible with each other. <amano>You can't install both B and C if A is propagated. <amano>If A isn't propagated, B and C can co-exist on the same system. <mange>Propagated inputs are an option of last resort. We try to only use them when we cannot solve things in other ways (e.g. by wrapping executables, as you've already been shown). Do you have a better solution than this? <amano>The build system can forbid different versions of the same library? <amano>Or, package writers can manually prevent version clashes? <amano>Manual resolution of library versions in one application isn't bad. <mange>I am a software developer. If I work on a Python project and install packages for development, the build system can't save me, nor can a package writer. Should Guix build me a broken profile? <mange>I thought we agreed a profile with two packages each depending on a different version of python-jinja2 would be broken, because Python can't load them? <amano>mange: Each application package is isolated from another. <mange>You're arguing "instead of propagated inputs, everyone should just add their dependencies to their search paths", which is a solution. Can you see the new problems that causes? <amano>Guix can isolate one python application from another. <mange>I am a software developer. I am installing libraries to develop against, not packages. Should Guix build me a broken profile? <amano>You just have to prevent different versions of the same library in one python application. <mange>s/not packages/not applications/ <amano>mange: I was a software developer, too. <amano>In theory, you don't need propagated inputs if python-build-system can automatically build search paths from python dependencies. <amano>You are not going to build a broken profile without propagated inputs. <mange>How would my development profile, with different versions of jinja2, not be broken? If Flask and webassets (two Python libraries) both ask for different versions of jinja2, then how can your hypothetical profile make them both happy? <amano>mange: You are not going to get different versions of jinja2 in your profile if jinja2 isn't propagated. <mange>If I have one version of jinja2, is it the one that Flask asked for? Or the one that webassets asked for? (Remember: they are asking for different versions.) <amano>Flask is a python library, right? <mange>Both Flask and webassets are Python libraries. <amano>If you launch guix shell, unpropagted inputs aren't going to enter your profile. <amano>If you install a python application, unpropgated inputs aren't going to enter your profile. <amano>You just need to make sure one python application doesn't use multiple versions of a library. <mange>So when I import jinja2 with Python my development profile, which version do I get? The one that Flask asked for, or the one that webassets asked for? <amano>Guix provides you with per-application isolation. <mange>I am developing the application. I am not yet finished, and I have made a mistake with my dependencies. Should Guix build me a broken development application? <mange>s/development application/development environment/ <amano>Does your python application depend on flask and webassets? <amano>You haven't actually laid out your use case. <amano>What exactly are you trying to do? <mange>Okay, I'm disengaging now. Thanks for the chat. :) <amano>What's wrong with using propagated inputs for efficiency? <amano>It seems you are saying that you use propragted inputs to detect multiple versions of the same library within one application. <amano>Don't give me IQ puzzles. Just give me the answer straight away. <amano>I'm not good at solving IQ puzzles. <amano>I'm tired. I don't want to solve zen koans... <futurile>I think take a break at this point. About 3-4 people have tried to explain it to you. But it's not getting across - always a challenges to explain things in a text environment. Take a break - come back to this later is my suggestion. <mange>I've been talking to you on and off for four hours, and we're going in circles. The answer is: propagated inputs cause a dependency to be installed into a profile when the package is. You can think through the consequences of this yourself. <amano>Is it so hard to just say that propagated inputs increase efficiency and force collision of multiple versions of the same library? <amano>If you compile a C application, absolute paths to dynamically linked libraries are etched into the compiled executable. That's very efficient since you no longer have to search paths after compilation. <amano>Python doesn't have that for now. So, for efficiency, propagated inputs are used. That's how I read the article. <nckx>Why bring efficiency into this? It seems to be the lens through which you want to view everything. The article doesn't mention it at all, that's all your addition. <futurile>I'm not going to answer further questions on this topic from you at this time because you're not learning. For example, you've just circled back to the point that mange explained to you in the backscroll. You've done this multiple times this morning. If you're not just trolling the channel the reality is you're not taking on new information. <amano>The consequence of putting things in profile is that there is only one python module path. <nckx>I agree with <you're not taking on new information> and <Take a break - come back to this later>, it's a good suggestion. This is going in circles and doesn't seem to be converging on anything. Different people have tried explaining different things each in their own different way, and we have reached the point of diminishing returns in asking the same basic questions an Nth time. <nckx>Instead, try playing around with Guix for a few days. It's how most of us got an intuition for what appears to be confusing. <dariqq>speaking of propagation: Is there a way to deal with the pkg-config problem without it? <nckx>You'll also get a better sense of which things are design decisions and which are gross hacks that even by Guix standards would be better dropped. Assuming that everything a programme does is considered a great idea by the programmer is bound to lead to disappointment. Guix is still incomplete. <nckx>dariqq: Is there a class of pkg-config problem that outright can't be solved by patching the .pc file? Honest question, I'm not a pkg-config expert and have only dealt with it as a packager. I might be blind to whole areas. <dariqq>nckx: neither am i, but a lot of packages seem to propagte things in order for pkgconfig to be able to find them. which has recently created a problem a for me because i couldnt install something because the porpagated gtk2 is conflicting with gtk3 (also propagated from another application) <dariqq>My workaround is to instead install a custom variant where the porpagated-inputs are moved to inputs <Viiru>Hmm. Does anyone know if there's a specific reason why emacs-next hasn't been updated to the pretest release? <futurile>ci.guix's substitute availability is really low <meaty>perhaps there should be some kind of notice when you try to run guix system reconfigure as a non-root user <RavenJoad>What is the function/macro I should use to mark a field in a define-configuration as deprecated? I saw define-deprecated/public-alias, but want to be sure. <mehrad>Is there a way to know which package in Guix provides 'pdflatex'? <sham1>This doesn't actually answer your question, but I'd assume texlive-pdftex <mehrad>thanks, it is more that what I have now. I'll give it a try. <Rutherther>mehrad: there is guix locate. But currently it builds the database from your own store. So if you don't have the package already it won't help you <mehrad>Rutherther: well, logically I don't have it, and that's why I'm searching for it :) is there any perspective to add something that can do this without having the whole universe in my store? <mehrad>on Arch for example, the `pacman -Ss pdflatex` exactly returns what the user should install and that's pretty handy <sham1>Would be useful if you could query the substitute server for that <sham1>Downside would be that you'd have to do it by querying the substitute server <mehrad>Rutherther: Thanks for the answer. It is one step forward from where I am and that's progress in my book. Thanks <mehrad>sham1: is there a way to do that? I don't have this in my guixfu notes <mehrad>I already tried 6 texlive-* packages including "texlive-pdftex" and "texlive-latex-uni8" and none of them provide pdflatex. Any insight is highly appreciated. <sham1>Oh I don't think that kind of a thing exists yet. It would probably have to be similar to guix weather, thi <Rutherther>I am afraid currently no way. There is a plan to make guix locate download a database. And substituters could build this database, populate it with all packages <mehrad>I ultimatly had to install "texlive" which is around 5GB form the substitutes server. I wich there was an easier way. <nckx>Elaborate upon what you mean post haste, mon ami. <nckx>My Guix is admittedly 2 days old but unless someone made a big mistake, it can't be significantly lower on master. <bbianomker>What's the reccomended way to install new desktops? I just want to install LXDE <bbianomker>when do i install packages using the root user vs just the normal user <ieure>bbianomker, Add the packages to your operating-system definition and `sudo guix system reconfigure path/to/system/config.scm' <nckx>futurile: Oh, I'm on x86_64. <bbianomker>How do I find where that file is? Do I need to make it? <nckx>Yes, we need more aarch64 hardware (or there's some other bottleneck) on CI. <ieure>bbianomker, Default location is /etc/config.scm, but you can put it anywhere. I keep mine in a Git repo in $HOME/projects. <Rutherther>you have to have this file already if you are on guix system <nckx>If you used the menu-driven installer, one will have been created for you that exactly matches your current system. <sneek>Welcome back jonsger, you have 1 message! <jonsger>works on master again, thanks to a patch from André Batista :) <Rutherther>I don't know how that core pattern does, but for me without the pattern, I get core dumps in the folder I ran the program for <dariqq>thanks to the person who talked about cargo2guix the other day. Currently trying to update my horrible package for fractal. Things are slightly more difficult because it is meson+cargo and them wanting git commits of the matrix-sdk. After fixing a lot of things and bootstrapping rust@1.79 i am finally getting cargo to start compiling . Lets hope everything goes well <dariqq>Only took completely reasonable 11k lines of scheme <Rutherther>btw there is already rust 1.81 in rust-team branch <dariqq>nvm it failed building matrix-sdk-crypto, this will be fun ... <dariqq>ACTION gives up on devendering cargo inputs <yaslam>what are the benefits of using guix on another distro <elpogo>i run guix on debian stable yaslam . you can get newer versions of packages than what's present on debian stable. which distro would you be running guix on? <Franciman>hi elpogo i tried runnig guix on debian stale too <elpogo>installing guix on your distro is great way get started with functional package management, and if you like it you can eventually make the switch to running a guix system. <yaslam>how much disk space does guix require ? <riabenko>any suggestions for installing software on debian-based pureos distro with dconf in propagated-inputs? i tried and it seems to disable some features in the phoc compositor, such as free floating windows <riabenko>yaslam: i currently have most of my software installed with guix . it still takes around 8 GB . it was a few gigabytes originally <elpogo>Franciman: does the guix kernel support your wifi radio? <dariqq>I have now successfully build fractal vendoring the crates manually. It should not be this hard just to build a chat client <elpogo>riabenko: is it 29gb because that's the free tier limit on your cloud VPS provider? <riabenko>elpogo: it is a rather small device. it has eMMC instead of HDD. the manufacturer decided that 30gb should be enough for the first batch. there is a premium batch with 128 gb <futurile>dariqq: congrats! Rust is hard in my experience! <dariqq>ive been spending too much time trying to make rust apps work. The whole ecosystem is just insane <ieure>lilyp, Seems like it failed to build the package cache? The "package-cross-build-system-error" makes it seem like this is a cross build -- maybe the issue is an arch-dependent thing and you're building for the native arch locally? <ieure>Guile has the most frustrating and useless stack traces of any language I have ever used. :( <lilyp>even if cross-builds are super borked, why would this break CI :< <sham1>ieure: you guys get stacktraces? Lucky <ieure>sham1, Weeeeeeeellll work has mandated that every start using Kotlin instead of Clojure, so the stacks border on Guile-level useless. <lilyp>nvm it just breaks the overview <sham1>From what I've understood, Clojure also has fairly useless stacktraces. And I'm saying this as someone who actively works in the JVM ecosystem <lilyp>I'll have you know that I recently got exceptions that were never thrown :) <ieure>sham1, Clojure stack traces are fine; Clojure *error messages* are horrible. <ieure>Kotlin heavily uses "coroutines," i.e. per-thread event loops for async programming, which means that whatever caused your problem happened on another thread and isn't in the stack you get. <ieure>I do not actually like async event loops, and Kotlin's implementation feels needlessly complicated. <sham1>Most languages do async badly. I like the Erlang model personally <ieure>Their docs are also horrible, instead of explaining what a CoroutineScope, CoroutineDispatcher, and CoroutineContext are, they're like "hold my beer, here's how to Do A Thing In IntelliJ" <sham1>call/cc can also be fun, although there's some futzing about there <riabenko>dariqq: Thank you for doing this. I was looking for fractal in guix just a few hours ago. <sham1>ieure: that's not really a surprise since it is of course an IJ thing <ieure>sham1, Yes, the whole language feels like a loss-leader to sell IntelliJ licenses. <ieure>I miss Clojure, which was a loss-leader to sell Datomic licenses. <sham1>And then Google basically made it mandatory for the vast majority of phones worldwide <dthompson>well if you like erlang's actorish model *and* lisp then you'll love goblins :) <ieure>dthompson, Yeah, I've played with it a bit, haven't done anything useful, but it seems very promising. <yaslam>hi guys i am trying to install guix in Virtualbox and for some reason when EXWM launches all the text is the colour of the background so I unable to see it <sham1>That sounds like a misconfiguration <dthompson>debugging *anything* async is tough, though. linear backtraces are rarely helpful on their own. <yaslam>sham1: default config out of the box <futurile>test that flew past was called 'test_dummy_verify' - I was waiting for it to pop up a window saying "are you still there dummy?" <dariqq>riabenko: upstreaming this to guix will bring back the horros of cargo i faced earlier: My current package relies on me manually creating a tarball with the vendored crates and then using local-file as a source. <robin>is anyone using plasma + x11 on guix? <robin>(as in, has it been known to work for anyone ever, or is it uncharted territory) <amano>I kept analyzing python build system, and it turns out that python applications don't propagate python dependencies, and python build system collects python packages to GUIX_PYTHONPATH and create a wrapper with GUIX_PYTHONPATH for python application. <amano>Only python libraries propagate python dependencies probably for guix shell? <amano>Guile libraries propagate guile dependencies, and guile applications don't propagate guile dependencies. That's becoming interesting.