AUR (en) - pyradio

Search Criteria

Enter search criteria

Search by

Keywords

Out of Date

Sort by

Sort order

Per page

Package Details: pyradio 0.9.3.11.10-1

Package Actions

Git Clone URL:	https://aur.archlinux.org/pyradio.git (read-only, click to copy)
Package Base:	pyradio
Description:	Internet radio player for the command line
Upstream URL:	https://github.com/coderholic/pyradio
Licenses:	MIT
Submitter:	sng
Maintainer:	sng
Last Packager:	sng
Votes:	9
Popularity:	0.000151
First Submitted:	2021-08-31 12:16 (UTC)
Last Updated:	2025-05-06 14:36 (UTC)

Dependencies (15)

python-dateutil (python-dateutil-git^AUR)
python-dnspython (python-dnspython-git^AUR)
python-netifaces (python-netifaces-plus^AUR)
python-psutil
python-requests
python-rich
python-build (make)
python-installer (make)
python-pip (make)
python-setuptools (make)
python-wheel (make)
mkvtoolnix-cli (mkvtoolnix-qt5^AUR) (optional) – fix mplayer recordings, add chapters to recordings
mplayer (mplayer-gui-svn^AUR) (optional) – as backend
mpv (mpv-light-pulse^AUR, mpv-git^AUR, mpv-build-git^AUR, mpv-full-luajit-git^AUR, mpv-amd-full-git^AUR, libmpv-git^AUR, mpv-full^AUR, mpv-full-git^AUR, mpv-full-build-git^AUR) (optional) – as backend
vlc (vlc-nox^AUR, vlc-git^AUR, vlc-luajit^AUR) (optional) – as backend

Required by (0)

Sources (1)

pyradio-0.9.3.11.10.tar.gz

Latest Comments

1 2 Next › Last »

sng commented on 2024-12-29 14:47 (UTC)

@blacktav

Yes, I know what you mean, it is frustrating, but I think it is unavoidable. I whish we could have an automated bumping mechanism for such cases, but aur packages are not officially supported, so...

Even manually bumping the package release would not guarantee that the package update would happen after the actual python update (on the user's machine), which makes the whole thing unreliable

blacktav commented on 2024-12-29 13:31 (UTC)

After a recent update, pyradio failed to start because modules could not be found Cause was modules being installed for python3.12 instead of active python3.13

Simple solution is to use "--rebuild" to force rebuilding of the package

Maybe bumping the package release could force this

sng commented on 2024-04-05 14:13 (UTC) (edited on 2024-04-05 14:13 (UTC) by sng)

And I will later then go to the github repo (issues) itself and leave the feedback there. It's more appropriate.

Yes!

Thank you very much!

Looking forward to your feedback!

m040601 commented on 2024-04-05 14:08 (UTC) (edited on 2024-04-05 14:12 (UTC) by m040601)

@sng

I am the current developer but I am not coderholic, the guy who started this project back in '11, but then lost
interest in it

Ahh ... I see now.

Pity he lost interest.

I say, pity, because "pyradio" is still one of the few "complete" text radio clients for Linux.

Especially the "radio-browser api" integration is in my opinion very important.

You should adopt and own the repo then. You are the one to have put so much work in it in the last years.

I think that having ttf-dejavu as a dependency is not such a big problem, or is it?
I would be perfectly happy to remove it too

Yeah, not so "bad" as xdg-utils.

But anyway, I think I'll better first compile and organize my thoughts and suggestions.

And I will later then go to the github repo (issues) itself and leave the feedback there. It's more appropriate.

sng commented on 2024-04-05 13:52 (UTC)

@m040601

I think that having ttf-dejavu as a dependency is not such a big problem, or is it?

I would be perfectly happy to remove it too

sng commented on 2024-04-05 13:49 (UTC)

@m040601 I am the current developer but I am not coderholic, the guy who started this project back in '11, but then lost interest in it

I just kind of "adopted" the repo back in '18 after submitting some PRs

So that seems to explain it ???

Any way. It would be nice if as core principle "pyradio" did not make any assumptions of what the user is running. Don assume a graphical desktop, a window manager, not even starting X/Wayland.

Keep it simple and bloat free. Always consider carefully if any thing should be optional or mandatory. Or have a fallback.

Thanks in advance.

Yes, this is what explains it...

And you are right, I just did not check for extra dependencies...

I will have a look into xdg-open alternatives

m040601 commented on 2024-04-05 13:41 (UTC) (edited on 2024-04-05 13:56 (UTC) by m040601)

@sng

Thanks for the reply.

I am the developer also ...

Ohh ???!!! So you are the "coderholic" guy also ? https://github.com/coderholic/pyradio

Nice. Thank you for the tool.

In the meantime I did my self some checking and found in the repo "docs/packaging.md":

....Linux users will have to install the "xdg-utils" package ....

.... Linux and macOS users will have to have installed a font that supports the "Unicode Geometric Shapes Block". Any font
mentioned in the Font Support for Unicode Block 'Geometric Shapes' page will do; as you can see these include DejaVu,
FreeMono, Unifont, etc, some of which will fopefully be installed by default.
....

So that seems to explain it ???

Any way. It would be nice if as core principle "pyradio" did not make any assumptions of what the user is running. Don assume a graphical desktop, a window manager, not even starting X/Wayland.

I see this a lot lately in many other tools mandatory imposing special fonts with cute icons, smileys and patches. Totally unnecessary.

Here is my personal opinion:

Keep it simple and bloat free. Always consider carefully if any thing should be optional or mandatory. Or have a fallback.

Dont break conventions or standards. Key bindings, default pagers, workflows etc.

People who like pyradio are terminal/text lovers. They want it simple and concise. Doing one thing well. Integrating nicely with other text tools if possible. They are already used to and have some "conventions" in their head (emacs, vim, or whatever). They dont want to relearn and have to memorize new paradigms/interfaces.

For those others who like it flashy and graphical. If they wanted a graphical radio browser with lotz of bells, whistles, flash colors, pictures, buttons they would be installing a graphical one to use with the mouse or gestures.

Thanks in advance.

sng commented on 2024-04-05 13:26 (UTC) (edited on 2024-04-05 13:28 (UTC) by sng)

Hi m040601

You are so right!

This is my mistake (I am the developer also)...

I will update asap

m040601 commented on 2024-04-05 13:15 (UTC) (edited on 2024-04-05 13:30 (UTC) by m040601)

Thanks for taking care of this PGKBUILD. Usefull. Hope that with enough votes it could be made into an official Arch package.

A question about dependencies. Mandatory versus optional.

I noticed this was introduced in the last updates.

+ depends = xdg-utils
+ depends = ttf-dejavu

This is really strange I first thought.

Pyradios is a TUI/CLI text tool.

Of course, you dont need to startx/X/Wayland or any desktop or window manager to use it.

Why would you need a font that only works in graphical environments for a text tools ? Why would a CLI/TUI tool need X11/graphical/desktop related things ?

And so my question:

Is this ttf-dejavu/xdg-utils a consequence of the developer of pyradio making some changes that "force" these mandatory(not optional) dependencies ?

I ask this because I see "xdg-utils" tools there.

And it is a tool that I hate, and forces you to have the commands "xdg-open" and "xdg-settings" on your system.

For others reading this. Dont confuse the specification "XDG" with this tool implementation "xdg-utils". The latter is not mandatory and it is a very bloated one. Read more,

Fortunately, the pyradio PKGBUILD maintainer himself, seems to be aware of this, and provides an "alternative" for those not using not wanting "xdg-utils".

• xdg-utils (busking-git^AUR, xdg-utils-slock^AUR, xdg-utils-lxqt^AUR, mimi^AUR, mimi-git^AUR, xdg-utils-handlr^AUR, opener^AUR, xdg-utils-betterlockscreen^AUR, mimejs-git^AUR, xdg-utils-mimeo^AUR)

So you can still "bypass it" if you have one of the other xdg-open "impersonators".

But still, it still looks too me too much confusion just for a simple text tool.