3 ms·

> The ergonomics around trying out modifications of these package definitions locally aren't as nice as I'd like, but it's been improving. I'd be curious to he

by mbakke 6y ago

> The ergonomics around trying out modifications of these package definitions locally aren't as nice as I'd like, but it's been improving. I'd be curious to hear what kind of modifications you do and how they can be made more comfortable. I suppose you are using object inheritance in a channel, file or manifest?

ryukafalz 6y ago
I haven't done that much, but generally those modifications are things like... adding a new package, updating an existing package, etc. As for how, it depends on what I'm doing. If I'm modifying a single package, I might reach for inheritance first (in a file or manifest), although it depends on whether or not that package is at the end of a dependency chain. If it is, inheritance is fine; I'll inherit the upstream version first, change a few fields, and try building/installing it. If not, though, I might be trying to update a library but the program I really care about is an application further down the chain; then I'll typically work from a local Guix checkout so that I can update the library then install the application. Regarding the ergonomics of each of these: - If I'm doing something that involves working on a Guix checkout... well, that involves looking up where to find Guix's source code, `git clone`ing it, finding the Guix revision I'm currently on with `guix describe` so I can check out the same one for consistency's sake, `make`ing it, `guix environment guix`, using `pre-inst-env`, etc. I don't really have a problem doing this, but I've also been working with Git and GNU/Linux for years now. It's not very approachable to beginners. Don't get me wrong, it's easier to make changes to Guix than it is to most distros, but I still think it could be better. - Inheritance can be pretty convenient, but of course when you finish working on something and want to go contribute a patch, you have to go get yourself a Guix checkout anyway and copy your changes over. I think in my ideal world, there would be a command like `guix edit`, where `guix edit foo` would do something like... give you a local editable checkout of Guix, open an editor to the file at the line where the start of the package is, give the user a quick way to build their new package, etc. I haven't thought through exactly what the UX would be, but essentially the idea is to have the closest thing possible to an "edit source of <package>" button. Bonus points if it can walk the user through the upstream contribution process, and maybe automate the more trivial commit messages for things like adding a new package. I always have to look up that format as I don't contribute packages very often. This is not to say that what's going on behind the scenes should be completely hidden (verbose flag that shows what commands you could have run?), but providing a simple on-ramp to contributions that doesn't require much pre-existing knowledge is huge for engaging beginners (and even non-beginners who just don't have much time on their hands).
- mbakke 6y ago
  Thanks for the detailed reply! I think most Guix hackers are so used to working directly with a git branch that we forget to cater for "power users" who just want some small edits here and there. Guix is very hackable as you mention, but with a very different design from e.g. Gentoo, where you can easily override anything in /etc/portage. I like your 'guix edit' idea; the command already exists, but it opens a read-only copy of the Guix source code by default... It would be really nice to add a tutorial of sorts to it and make it interactive. Note there is an Emacs 'yasnippet' that fills out part of the commit message: https://guix.gnu.org/manual/devel/en/guix.html#The-Perfect-Setup https://guix.gnu.org/manual/devel/en/guix.html#The-Perfect-S... I agree that the onboarding story could be better. If emacs-guix could guide a user all the way from 'guix edit' to 'git send-email' that would be nothing short of incredible. Thanks for your thoughts. :-)
  - ryukafalz 6y ago
    Thank you for your work on Guix! Despite the rough edges that I see using it daily, I do think Guix or something close to it is the future. :) And thanks for the tip about the snippets!

by mbakke 6y ago

ryukafalz 6y ago

I haven't done that much, but generally those modifications are things like... adding a new package, updating an existing package, etc. As for how, it depends on what I'm doing. If I'm modifying a single package, I might reach for inheritance first (in a file or manifest), although it depends on whether or not that package is at the end of a dependency chain. If it is, inheritance is fine; I'll inherit the upstream version first, change a few fields, and try building/installing it. If not, though, I might be trying to update a library but the program I really care about is an application further down the chain; then I'll typically work from a local Guix checkout so that I can update the library then install the application. Regarding the ergonomics of each of these: - If I'm doing something that involves working on a Guix checkout... well, that involves looking up where to find Guix's source code, `git clone`ing it, finding the Guix revision I'm currently on with `guix describe` so I can check out the same one for consistency's sake, `make`ing it, `guix environment guix`, using `pre-inst-env`, etc. I don't really have a problem doing this, but I've also been working with Git and GNU/Linux for years now. It's not very approachable to beginners. Don't get me wrong, it's easier to make changes to Guix than it is to most distros, but I still think it could be better. - Inheritance can be pretty convenient, but of course when you finish working on something and want to go contribute a patch, you have to go get yourself a Guix checkout anyway and copy your changes over. I think in my ideal world, there would be a command like `guix edit`, where `guix edit foo` would do something like... give you a local editable checkout of Guix, open an editor to the file at the line where the start of the package is, give the user a quick way to build their new package, etc. I haven't thought through exactly what the UX would be, but essentially the idea is to have the closest thing possible to an "edit source of <package>" button. Bonus points if it can walk the user through the upstream contribution process, and maybe automate the more trivial commit messages for things like adding a new package. I always have to look up that format as I don't contribute packages very often. This is not to say that what's going on behind the scenes should be completely hidden (verbose flag that shows what commands you could have run?), but providing a simple on-ramp to contributions that doesn't require much pre-existing knowledge is huge for engaging beginners (and even non-beginners who just don't have much time on their hands).

mbakke 6y ago
Thanks for the detailed reply! I think most Guix hackers are so used to working directly with a git branch that we forget to cater for "power users" who just want some small edits here and there. Guix is very hackable as you mention, but with a very different design from e.g. Gentoo, where you can easily override anything in /etc/portage. I like your 'guix edit' idea; the command already exists, but it opens a read-only copy of the Guix source code by default... It would be really nice to add a tutorial of sorts to it and make it interactive. Note there is an Emacs 'yasnippet' that fills out part of the commit message: https://guix.gnu.org/manual/devel/en/guix.html#The-Perfect-Setup https://guix.gnu.org/manual/devel/en/guix.html#The-Perfect-S... I agree that the onboarding story could be better. If emacs-guix could guide a user all the way from 'guix edit' to 'git send-email' that would be nothing short of incredible. Thanks for your thoughts. :-)
- ryukafalz 6y ago
  Thank you for your work on Guix! Despite the rough edges that I see using it daily, I do think Guix or something close to it is the future. :) And thanks for the tip about the snippets!