IRC channel logs


back to list of logs

<civodul>Hello Guix!
<civodul>uh, "guix import pypi python-xlib" fails with "No source release"
<Steap_>yes, the link to the .tar.gz is not specified in the json
<civodul>yeah the link on the web page points to a sourceforge directory
<Steap_>civodul: I think we're kind of screwed, unless we want to implement some sourceforge-specific stuff...
<civodul>for "guix import pypi python-xlib"?
<civodul>maybe the importer could handle that more gracefully, somehow
<davexunit>what's the issue?
<civodul>by inserting a fake URL when the actual download URL is missing
<civodul>davexunit: "guix import pypi python-xlib" fails with "No source release"
<davexunit>ah okay
<davexunit>yeah, if there's no source release, I guess we should leave a blank for the packager to fill in.
<jmd>Just curious: Why does the system installer appear to download 2 distinct versions of almost every package?
<civodul>alezost: the next thing that comes on my guix.el wishlist would be a command that runs "guix pull" and then restarts the REPL and refreshes the buffers
<civodul>if i may ;-)
<davexunit>I need to work guix.el into my workflow more.
<civodul>the nice thing is that it works out of the box
<civodul>and then everything in the UI is natural
<civodul>well, to someone with an Emacs background ;-)
<davexunit>and copy its functionality for guix-web
<civodul>oh yes
<civodul>and we'll need to integrate guix-web in the repo someday :-)
<davexunit>last night I started refactoring the JS code I've written thus far.
<davexunit>and wrote an endpoint to serialize generations as JSON
<civodul>ijp: what's up with the scheme2js compiler? :-)
<davexunit>so now I have a generations view. just need to add the stuff that guix.el has to edit them.
<civodul>oh nice, i should give guix-web another trry
<davexunit>there's not much more there since you tried it.
<davexunit>you install packages individually, but you can't install multiple, or delete, or upgrade yet.
<civodul>i hadn't tried that part
<davexunit>I really want to add user authentication so that it can be a system service.
<davexunit>does guix.el handle multiple profiles?
<civodul>not yet
<davexunit>okay, just wondering. I would like to support that, too.
<civodul>yes, that'd be useful
<davexunit>are there any other 'views' for guix.el besides packages and generations?
<davexunit>(I should just look myself, but I'm not on a guix machine atm)
<civodul>there's guix-installed-packages, guix-newest-available-packages, guix-obsolete-packages
<civodul>and guix-generations
<civodul>and then there's per-package views
<davexunit>I need to change my per-package view to be part of the single-page application instead of a static page.
<jmd>Are there any wireless interfaces ?
<civodul>jmd: in guix.el? :-)
<jmd>in Guix
<alezost>davexunit: civodul: guix.el handles multiple profiles: "M-x guix-set-current-profile" and go ahead with the selected profile
<alezost>civodul: yes, "guix pull" was the next in the todo list :-)
<civodul>jmd: there's wireless-tools (iwconfig, etc.) and wpa-supplicant
<civodul>alezost: ooh, nice, i forgot about guix-set-current-profile
<davexunit>alezost: cool, I'll have to add a setting in guix-web for the same thing.
<jmd>But are there any drivers?
<civodul>would be cool if we could use C-u M-x guix-installed-packages
<civodul>jmd: yes, but typically for Atheros based Wifi things
<alezost>civodul: what C-u should mean there?
<civodul>like the RYF-stamped dongles
<civodul>alezost: it would prompt for a profile name
<alezost>civodul: I don't see the benefit as you can use "M-x guix-set-current-profile" and then "M-x guix-installed-packages"
<civodul>it just felt "natural"
<civodul>it's a quite common convention
<civodul>but yeah, guix-set-current-profile works as well
<mthl>hi there
<mthl>thinking of articulation of 'guix-set-current-profile and 'guix-installed-packages, it makes me think of the way google-translate melpa package work
<civodul>hey mthl
<civodul>what do you mean?
<civodul>i've never used it
<mthl>the default if to prompt you the language you want to select, and if you configure a default langage it automatically translate this way
<alezost>civodul: it's not natural for me: should "C-u M-x guix-generations" or "C-u M-x guix-obsolete-packages" do the same? I find it natural to set a profile and work with it
<mthl>and then if you want to specify another languages you use universal argument
<civodul>yes, that's what i had in mind
<civodul>alezost: C-u would just prompt for the thing, effectively having the same effect as guix-set-current-profile followed by the actual operation
<civodul>dunno, maybe i'm overlooking something
<mthl>what do you think of guix-installed-packages default to prompt profile to select, and you have to add a variable to bypass that (for speed) and have to use C-u guix-installed-packages to select something else than the default profile
<davexunit>C-u M-x guix-installed-packages is natural to me
<alezost>ok, then should "C-u M-x guix-installed-packages" change the currently used profile, so that other commands would use it, or would it be changed just for listing installed packages?
<davexunit>hmm, good question.
<mthl>what other commands make use of profiles?
<alezost>mthl: well you install, delete, update, describe packages from a list of packages – all of them use some profile
<alezost>also all commands for selecting packages use profile to get information if a package is installed there or not
<alezost>the bottom line: all commands use profile
<mthl>my first intuition is that C-u should be only for temporary switch, not to change a variable, the command "guix-set-current-profile" should be what change the variable
<mthl>the more i think about it, the more i feel mixing setting profile with actions on packages is confusing
<civodul>alezost: re C-u, i think the problem is that if there's an open installed-packages buffer, and then you C-u guix-generations for another profile, then what happens when you hit 'g' in the first buffer, right?
<alezost>mthl: mixing? but actions can't be performed outside profile: you install or delete packages in a partucular profile
<alezost>civodul: after "g" a buffer with installed packages will be updated for the current profile
<civodul>yes, so that's the problem, i think
<civodul>there's a global "current profile"
<civodul>whereas C-u could lead to think that the profile is per-buffer
<civodul>yeah, maybe better forget about that suggestion :-)
<alezost>I think that global current profile is the only right solution, and I don't see any problems with the current system, but I can add "C-u" to "guix-installed-packages" and "guix-obsolete-packages" if you want
<davexunit>eventually, it could probably be handled similar to how magit can work with many git repos.
<alezost>davexunit: what do you mean exactly?
<civodul>alezost: there's no real problem with the current solution, i'm really just discussing the aesthetics
<davexunit>alezost: with magit, you can have a whole bunch of different types of magit buffers open that are working with different repositories.
<davexunit>different status, log, etc.
<mthl>alezost: what i mean is that if you make C-u M-x guix-installed-packages change the profile you have to make all packages related commands the same, which can limit the possibility of use of C-u.
<alezost>davexunit: oh, I see what you mean. Well this can be easily done if "guix-current-profile" variable will become buffer-local
<davexunit>the buffer names would just need some indication of which profile they are working with
<alezost>mthl: davexunit: civodul: thanks, I realized what you mean; I will look at it later
<davexunit>civodul: do we have anyway to avoid the "guix installation image installs an old guix" issue from the last release?
<civodul>davexunit: no :-/
<civodul>we can mitigate it
<civodul>by making the "old" Guix not really old