Message ID | 20210227223440.18685-1-lle-bout@zaclys.net |
---|---|
State | Accepted |
Headers | show |
Series | [bug#46823,1/3] gnu: Add python-readability. | expand |
Context | Check | Description |
---|---|---|
cbaines/comparison | success | View comparision |
cbaines/git branch | success | View Git branch |
cbaines/applying patch | success | View Laminar job |
cbaines/issue | success | View issue |
Hello! If I do not wrap XDG_DATA_DIRS, then in a --pure environment gfeeds cannot find gsettings-desktop-schemas and wont start. I also figured I'd depend on mpv and specify it's full path in the config by default (instead of just the PATH's relative "mpv") since it is useful for basic functionality of the software (rss on feeds providing video links). Depending on the user's profile, the user is still free to change it. Does that sound OK to you? Appreciate the review, Thanks!
Hello, Léo Le Bouter via Guix-patches via <guix-patches@gnu.org> writes: > If I do not wrap XDG_DATA_DIRS, then in a --pure environment gfeeds > cannot find gsettings-desktop-schemas and wont start. It looks like a common deed across packages. > I also figured I'd depend on mpv and specify it's full path in the > config by default (instead of just the PATH's relative "mpv") since it > is useful for basic functionality of the software (rss on feeds > providing video links). Depending on the user's profile, the user is > still free to change it. Does that sound OK to you? It is better than propagating it anyway. I think that's fine. Note that (native-)inputs should be sorted alphabetically, and descriptions ought to be full sentences. Otherwise, LGTM. Regards,
On Fri, 2021-03-05 at 17:32 +0100, Nicolas Goaziou wrote: Thanks for the review! > Note that (native-)inputs should be sorted alphabetically, and > descriptions ought to be full sentences. I did the descriptions but did not sort all *inputs because it is quite troublesome to do so editing commit history etc.. I don't like doing it manually and don't have any tooling, also don't think it is very worthwhile use of my time, nor do I think it adds much value to GNU Guix. If you have any tooling to suggest to do it easily in Emacs then I'll happily do that in every of my contributions by default. I also moved gfeeds to gnu/packages/syndication.scm as that's where it sits better I think, it not being an official GNOME project. Pushed all in 373e5fc96724fd38bb1263e4af90932ea36f596b. Léo
Hello, Léo Le Bouter <lle-bout@zaclys.net> writes: > On Fri, 2021-03-05 at 17:32 +0100, Nicolas Goaziou wrote: >> Note that (native-)inputs should be sorted alphabetically, and >> descriptions ought to be full sentences. > > I did the descriptions but did not sort all *inputs because it is quite > troublesome to do so editing commit history etc.. I don't like doing it > manually and don't have any tooling, also don't think it is very > worthwhile use of my time, nor do I think it adds much value to GNU > Guix. I obviously cannot tell what is worth of your time. However, sorting inputs alphabetically has some value. For example, it makes it easier to add more inputs later, as it becomes less tedious to check for duplicates. > If you have any tooling to suggest to do it easily in Emacs then > I'll happily do that in every of my contributions by default. What about a basic M-x sort-lines ? Note that you need to be cautious about the first and last inputs, as opening and closing parens should be sent to another line there. If you don't want to special-casing first and last inputs, there's the more "advanced" M-x sort-regexp-fields RET (".+?".*?) RET \& RET while selecting the full input field (with C-M-SPC). HTH,
On Sat, 2021-03-06 at 11:13 +0100, Nicolas Goaziou wrote: > > I obviously cannot tell what is worth of your time. What do you mean? > However, sorting inputs alphabetically has some value. For example, > it > makes it easier to add more inputs later, as it becomes less tedious > to > check for duplicates. Agreed but seeing all that has to be done in GNU Guix.. we can massively sort *-inputs another time can't we? Or if there's an automated pre-commit hook or Emacs "guix-packageer-mode" someone can make, I'll happily install it. > What about a basic M-x sort-lines ? Note that you need to be cautious > about the first and last inputs, as opening and closing parens should > be > sent to another line there. That's what I was using and yes first and last lines makes it quite annoying. > If you don't want to special-casing first and last inputs, there's > the > more "advanced" > > M-x sort-regexp-fields RET (".+?".*?) RET \& RET > > while selecting the full input field (with C-M-SPC). Thank you that's really great, will use! Léo
Hi, On Sat, 06 Mar 2021 at 18:44, Léo Le Bouter via Guix-patches via <guix-patches@gnu.org> wrote: > On Sat, 2021-03-06 at 11:13 +0100, Nicolas Goaziou wrote: >> However, sorting inputs alphabetically has some value. For example, >> it >> makes it easier to add more inputs later, as it becomes less tedious >> to >> check for duplicates. > > Agreed but seeing all that has to be done in GNU Guix.. we can > massively sort *-inputs another time can't we? Or if there's an > automated pre-commit hook or Emacs "guix-packageer-mode" someone can > make, I'll happily install it. I am not convinced tooling for sorting inputs is worth here. I mean sorting the inputs (if there are not) or keeping sorted the inputs list is so quick and easy compared to other parts of the packaging that sorting is more a discipline than a concrete issue, similarly as two spaces for the description’s sentences. IMHO. However, “guix lint” could warn when the inputs are not sorted. And it remembers me this bug report: <http://issues.guix.gnu.org/issue/42289> Cheers, simon
diff --git a/gnu/packages/python-xyz.scm b/gnu/packages/python-xyz.scm index c10a55e8b6..1ff51d1b2c 100644 --- a/gnu/packages/python-xyz.scm +++ b/gnu/packages/python-xyz.scm @@ -23985,3 +23985,26 @@ and frame grabber interface.") (description "A screencast tool to display your keys inspired by Screenflick.") (license license:gpl3+))) + +(define-public python-readability + (package + (name "python-readability") + (version "0.3.1") + (source + (origin + (method url-fetch) + (uri (pypi-uri "readability" version)) + (sha256 + (base32 + "1b8gq3g2zwvx0aivvdg56cc0bn7xw6f2v6psmxdx9aiipkw0s0zr")))) + (build-system python-build-system) + (home-page + "https://github.com/andreasvc/readability/") + (synopsis + "Measure the readability of a given text using surface +characteristics") + (description + "An implementation of traditional readability measures based on simple +surface characteristics. These measures are basically linear regressions +based on the number of words, syllables, and sentences.") + (license license:asl2.0)))