Re: The e(macs)lephant in the room and the Guix Bang
>Hi, for some reason emacs has become the elephant in the room of the discussion on contributing to guix. >Regardless of one's opinion of emacs, I just want to add that this is itself strange. I have contributed some (package definition) patches to guix, all without using emacs. >I am not an emacs user, so emacs is not necessary for contributing to guix. For what it's worth, the emacs-motif package in Guix was my addition. I don't use it myself. I don't use emacs either (because it's so impenetrable), so I just use kate instead, which isn't a great environment for me either. It has rainbow parens, but it doesn't balance them, which is a hassle. I keep using it though due to lack of time to browse through alternatives. I heard about guile-studio, but it doesn't appear to have a dark mode, and I imagine trying to add one would require a bunch of emacs-style screwing around with it. https://archive.fosdem.org/2022/schedule/event/lispforeveryone/ This is the only setup for coding in lisp that has actually looked attractive to me. (Coding in wisp with colored blocks that transpiles to s-expressions) Though I haven't had the time (and probably expertise) to set it up for myself.
Re: Stuck patch 64345
Hi nigko, On Fri, Sep 22 2023, nigko wrote: > As far as I understand the reason for this behavior is that since I sent > the patch the content of the gnu/packages/maths.scm was modified by > another patch(es) and now git is unable to apply my old patch onto new Yes! It's probably your copyright line at the top. > What am I supposed to do to promote my stuck > patch? Please rebase your patch onto the current 'master' branch from Savannah. > Should I resend it anew? Just amend your existing bug. Please also tag your submission with '-v2' as explained here. [1] Thank you for your valuable contribution to Guix! Kind regards Felix [1] https://guix.gnu.org/manual/en/manual/devel/en/html_node/Sending-a-Patch-Series.html#Single-Patches-1
Re: How can we decrease the cognitive overhead for contributors?
> I think a lot of this discussion is stuck on what is better web or > email. Where it doesn't have to be. > > What we instead need to do is acknowledge that some people like the web > approach. > > And accommodate them so we can have guix used by more people. Simple as that > :D Exactly. An option is to make some kind of user-story based documentation might help? For example: -- - If you are used to a web-based git forge such as gitlab or github, Guix's approach to collaboration might seem a little bit hard at the beginning. Guix uses an email based approach, like many other GNU projects do. Email based approach relies on sending commits as patches that can be later applied by commiters and maintainers. Thee patches are sent via email, in plain text, instead of using a website for a Pull- or Merge- Request. You don't have to worry about the format of the emails, as git is able to generate them for you: $ git commit ... $ git format-patch ... If you configure git properly (link to how to do it), git can send those emails to guix automatically (see Using Git Send Mail). If you prefer, you can copy the content of the file `format-patch` generates in a plain text email, or attach it and send it to `guix-patches`. When that email is received a bug report will be opened in guix's issue system, where you can further discuss, as you would do in any other issue board or merge- or pull- -request discussion. The discussion is available at `URL` and looks like `screenshot`. If you want to share a series of patches... -- Something like that (done with more care and attention than what I just did), might help newcomers. It's mostly the same our documentation says, but our documentation currently (I think) relies too much on the people knowing what everything means. Maybe a deeper contribution guide might be an interesting thing to write down... Also including some introduction to the internals and how to write a build-system... Stuff like that is always useful. It has to be properly maintained though, but even if it is out of date, it's still a valuable resource to have some info about the *concepts*. (we can always put the date of the latest change and a note: this documentation is designed to explain the concepts, the specific details might be out of date, but the concepts remain). Or something, I don't know. But I'm open to try it :) The case of the Changelog commits has been discussed and its important too. We need to be able to make contributors learn how much they need to write down in the commit messages. I tend to write too much, and I don't think any of my patches have been applied without changes in the commit message. For example, in guix we often do (I just invented the name): gnu: Add lolo * gnu/packages/engineering.scm(lolo): New variable. Is that enough to describe the addition of a new package? If you know what you are looking for it might be, but it looks like an automatism commiters have that is not communicated properly. What if there's something in a `let` i changed? I have to list that too? What if...? Some help on that might be useful. And also, explaining how important it is to follow the jargon we use in the commit messages. Or how long should our explanations be... Just to help people don't feel overwhelmed about it, nothing more than that (and nothing less!). I don't know if this adds anything new to the conversation. Cheers!
Re: How can we decrease the cognitive overhead for contributors?
On 9/22/23 18:14, Imran Iqbal wrote: On Sun, Sep 03, 2023 at 05:45:41PM +, Ekaitz Zarraga wrote: I use protonmail and they don't provide smtp access so I can't do git send-mail as easy as other people do. A mail provider not allowing SMTP is a git forge that does not allow git push. This is not Guix's fault, but it's a problem Guix doesn't help fix either. This is not on guix to fix, this in you with your choice of mail provider. This doesn't mean I'm against the email based approach, in fact, I really like it. The main problem I see is many people inside guix are not sensible to people's problems and tastes. The problem is people's tastes are "we need to use the web browser for everything" which is what computers have become in a advertising and VC funded world. We should not be forcing that on people. Some people are forced to use tools for several reasons, too. But text editing and email the two things which there are a plethora of tools, and it's very hard to imagine a scenario where someone is forced into using one. This is what I mean when I say many times emacs is kind of mandatory, and this thread is kind of a demonstration of what I meant because the main discussion evolved to: you can use this or that in emacs to ease the dev experience. This is because emacs is a lisp machine that just happens to let you edit text. If you are working in a lisp-y language, emacs provides the best development experience. Emacs also lets you hand mail inside of emacs (among many many other things). This does not mean you are forced to use emacs. I use neovim and neomutt for my needs. I don't think software we use is the main problem, but the fact that we are not always sensible with other people's experience. Imagine a different scenario, where instead of this being about email it was around guile. Would it be fair to say that a Guix makes it hard to contribute by choosing to be implemented in guile? And that Guix should move towards using another language that more people are familiar with like python or javascript? Personally I don't think its fair to ask Guix to move away from emails because folks are more familiar with using web browsers for everything. I think a lot of this discussion is stuck on what is better web or email. Where it doesn't have to be. What we instead need to do is acknowledge that some people like the web approach. And accommodate them so we can have guix used by more people. Simple as that :D Its free software and power to the person that using the software after all. MSavoritias
Re: How can we decrease the cognitive overhead for contributors?
Hi, > On Sun, Sep 03, 2023 at 05:45:41PM +, Ekaitz Zarraga wrote: > > > I use protonmail and they don't provide smtp access so I can't do git > > send-mail as easy as other people do. > > > A mail provider not allowing SMTP is a git forge that does not allow git > push. This is a feeling, not a fact. > > This is not Guix's fault, but it's a problem Guix doesn't help fix either. > > This is not on guix to fix, this in you with your choice of mail > provider. I didn't say it's a problem Guix needs to fix. Also, what I'm trying to say here is maybe I didn't have the chance to choose my email provider. This is the exact behavior that I was saying it's not helpful. The email based approach is fantastic, and as good as it is, is flexible enough to let me use it even if I don't have SMTP access. What I think Guix docs lack is an explanation for those users like me, that don't have the privilege or the mental clarity to choose an email provider that matches your standards. > > This doesn't mean I'm against the email based approach, in fact, I really > > like it. The main problem I see is many people inside guix are not > > sensible to people's problems and tastes. > > The problem is people's tastes are "we need to use the web browser for > everything" which is what computers have become in a advertising and VC > funded world. We should not be forcing that on people. This is a projection, not what I meant. And even with that, if everyone wants to use the browser for everything maybe, if what we want is to *actually* reduce the cognitive overhead of people we *should* consider giving them a chance. Or should we *correct* people's tastes because they are wrong, as you suggest here? I'm not asking Guix to change the tools but the information about them. Make them more approachable doesn't necessarily mean to use a flashy web application imho. It means to give tools and knowledge, or at least to give enough pointers to that knowledge to let people jump in and feel comfortable in an easy way. So, in any case I meant what you are implying here, and I even find slightly offensive that kind of comment. It feels pretty insensible and purposely misleading. (Also: VCs and advertising have nothing to do with this, people who proposed forges proposed quite reasonable alternatives) > > Some people are forced to use tools for several reasons, too. > > But text editing and email the two things which there are a plethora of > tools, and it's very hard to imagine a scenario where someone is forced > into using one. Some people can't install things in their devices, or they can't access the network using certain protocols. Giving alternatives helps that group of people. > > This is what I mean when I say many times emacs is kind of mandatory, and > > this thread is kind of a demonstration of what I meant because the main > > discussion evolved to: you can use this or that in emacs to ease the dev > > experience. > > This is because emacs is a lisp machine that just happens to let you > edit text. If you are working in a lisp-y language, emacs provides the > best development experience. Emacs also lets you hand mail inside of > emacs (among many many other things). This does not mean you are forced > to use emacs. I use neovim and neomutt for my needs. Again, this comment assumes I don't understand the reasons behind it. The problem I'm trying to point is not that emacs is not great, but the fact that new people to the project has tons of info about emacs and around zero about any other editor or configuration, giving them the false (as you point) image that emacs is mandatory to work in guix. It's a matter of sensibility, exactly the thing you are not having here. > > I don't think software we use is the main problem, but the fact that we > > are not always sensible with other people's experience. > > Imagine a different scenario, where instead of this being about email it > was around guile. Would it be fair to say that a Guix makes it hard > to contribute by choosing to be implemented in guile? And that Guix > should move towards using another language that more people are familiar > with like python or javascript? That argument is not a fair argument either. Guile is structural in Guix, but emails are not and (you said it) emacs is not either. Also, what we are trying to do here is to reduce the cognitive overhead of *contributors*, not from every possible individual in the world. This is not only misleading, but unfair with my comment. You nitpicked every part of my message you could use for your final argument. Which is the following: > Personally I don't think its fair to ask Guix to move away from emails > because folks are more familiar with using web browsers for everything. First, I didn't, and most of the people didn't, ask Guix to move away from emails. Second, folks that are more familiar with web browsers are not inferior to the users that like using the email. If the majority o
Re: How can we decrease the cognitive overhead for contributors?
Imran Iqbal writes: > Personally I don't think its fair to ask Guix to move away from emails > because folks are more familiar with using web browsers for everything. Imran, you bring up good points. I wanted to state that I share this opinion: Guix should not move away from emails. I view this conversation as discussing root-causes and ways to address those root causes through addition, not subtraction. I hope that helps to assuage your concerns.
Re: OCI-backed Guix System Services
Hi Ricardo, On 9/21/23 00:12, Ricardo Wurmus wrote: Because integration with Shepherd is nice I wrote the Swineherd which serves a related need: https://github.com/BIMSBbioinfo/swineherd I saw that but I still haven't managed to find the time to play with it, it looks quite cool :) I'd love to be able to drop docker compose for local development environment in favor of something like the Swineherd. giacomo
Re: How can we decrease the cognitive overhead for contributors?
On Sun, Sep 03, 2023 at 05:45:41PM +, Ekaitz Zarraga wrote: > I use protonmail and they don't provide smtp access so I can't do git > send-mail as easy as other people do. A mail provider not allowing SMTP is a git forge that does not allow git push. > This is not Guix's fault, but it's a problem Guix doesn't help fix either. This is not on guix to fix, this in you with your choice of mail provider. > This doesn't mean I'm against the email based approach, in fact, I really > like it. The main problem I see is many people inside guix are not > sensible to people's problems and tastes. The problem is people's tastes are "we need to use the web browser for everything" which is what computers have become in a advertising and VC funded world. We should not be forcing that on people. > Some people are forced to use tools for several reasons, too. But text editing and email the two things which there are a plethora of tools, and it's very hard to imagine a scenario where someone is forced into using one. > This is what I mean when I say many times emacs is kind of mandatory, and > this thread is kind of a demonstration of what I meant because the main > discussion evolved to: you can use this or that in emacs to ease the dev > experience. This is because emacs is a lisp machine that just happens to let you edit text. If you are working in a lisp-y language, emacs provides the best development experience. Emacs also lets you hand mail inside of emacs (among many many other things). This does not mean you are forced to use emacs. I use neovim and neomutt for my needs. > I don't think software we use is the main problem, but the fact that we > are not always sensible with other people's experience. Imagine a different scenario, where instead of this being about email it was around guile. Would it be fair to say that a Guix makes it hard to contribute by choosing to be implemented in guile? And that Guix should move towards using another language that more people are familiar with like python or javascript? Personally I don't think its fair to ask Guix to move away from emails because folks are more familiar with using web browsers for everything.
Re: Version from file in a package
Hi Reza, I believe local-file should import (guix utils) and use current-source-directory. Something like: (define %cwd (current-source-directory)) (let ([...] (version-file (string-append %cwd "/VERSION")) [...] (source (local-file (string-append %cwd "/../..") "my-package-checkout" [...] The current directory may not be where the VERSION file is. giacomo
Version from file in a package
Hi List
Following the excellent blog post from Ludo [1] to guixify my python
project, I wanted to include a version string from file to have a single
source for the guix files and also for the python pyproject.toml file.
Something along this:
(define-public my-package
(let* ((vcs-file? (or (git-predicate %source-dir) (const #t)))
(version-file "VERSION")
(version-from-file (call-with-input-file version-file get-string-all)))
(package
(name "my-package")
(version version-from-file)
(source (local-file "../.." "my-package-checkout"
#:recursive? #t
#:select? vcs-file?))
(build-system pyproject-build-system)
...
this seems to work when I build locally but throws an error when I build
after a guix pull:
(exception system-error (value "open-file") (value "~A: ~S") (value ("No
such file or directory" "VERSION")) (value (2)))
How can I achieve this?
Thanks for your input!
Best,
Reza
[1]
https://guix.gnu.org/en/blog/2023/from-development-environments-to-continuous-integrationthe-ultimate-guide-to-software-development-with-guix/
--
Reza Housseini
This message is signed with my GnuPG key:
C0F3 0812 9AF2 80F4 0830 C2C1 C375 C6AF 0512 5C52
OpenPGP_0xC375C6AF05125C52.asc
Description: OpenPGP public key
OpenPGP_signature
Description: OpenPGP digital signature
Stuck patch 64345
Hello Guix! Almost three months ago I sent a patch https://issues.guix.gnu.org/64345 introducing a package reduce-csl, a computer algebra system Reduce similar to Maxima. It was successfully built on major architectures and acquired a 'green' status, waiting for a review. But then some dramatic changes happened on https://qa.guix.gnu.org/ and my patch went to a 'gray' zone. Recently a massage with the content Unable to apply patches Applying: gnu: Add reduce-csl. Using index info to reconstruct a base tree... M gnu/packages/maths.scm Falling back to patching base and 3-way merge... Auto-merging gnu/packages/maths.scm CONFLICT (content): Merge conflict in gnu/packages/maths.scm error: Failed to merge in the changes. hint: Use 'git am --show-current-patch=diff' to see the failed patch Patch failed at 0001 gnu: Add reduce-csl. When you have resolved this problem, run "git am --continue". If you prefer to skip this patch, run "git am --skip" instead. To restore the original branch and stop patching, run "git am --abort". has appeared on https://qa.guix.gnu.org/issue/64345 As far as I understand the reason for this behavior is that since I sent the patch the content of the gnu/packages/maths.scm was modified by another patch(es) and now git is unable to apply my old patch onto new commits automatically. What am I supposed to do to promote my stuck patch? Should I resend it anew? Regards, N Y
