Package Details: mpdris 1.2.0-1

Git Clone URL: https://aur.archlinux.org/mpdris.git (read-only, click to copy)
Package Base: mpdris
Description: A MPD client implementing the dbus MPRIS standard written in rust
Upstream URL: https://github.com/jasger9000/mpDris
Licenses: MIT
Conflicts: mpdris-bin, mpdris-git
Provides: mpdris
Submitter: jasger
Maintainer: jasger
Last Packager: jasger
Votes: 1
Popularity: 0.35
First Submitted: 2025-02-09 16:50 (UTC)
Last Updated: 2025-02-15 14:35 (UTC)

Latest Comments

jasger commented on 2025-02-15 22:01 (UTC)

You're correct, I can also reduce all the conflicts to just 'mpdris' since they all provide 'mpdris'.
Will do with the next update.

m040601 commented on 2025-02-15 21:18 (UTC) (edited on 2025-02-15 21:19 (UTC) by m040601)

13 conflicts=('mpdris-bin' 'mpdris-git')

By default the PKGBUILD "XXX" doesnt need this. That is for the PKGBUILD variants "XXX-bin" and/or "XXX-git". It is their job to say that.

jasger commented on 2025-02-11 16:29 (UTC)

It is only 1 day old.

Sorry, I wasn't clear on that. I meant the repo as a whole which has been around since 6 months. I was also referring more to the config file, which if I change its name or path would basically mean a v2.0.

I'll change the description together with the next update because I don't think it's worth making whole new pkgrel just for that change.

m040601 commented on 2025-02-10 22:23 (UTC)

... the package is public, 
... introducing breaking changes and making everyone's installs not work anymore.
    First      2025-02-09 16:50 (UTC)
  Submitted:

It is only 1 day old. I dont think that many people have even found it. That is why I pestered you now so much about the PKGBUILD name. When it is old on the AUR, then it will be too late to change the name.

Description:  A MPD client implementing the dbus MPRIS standard

At least you can change that to

Description:  A MPD client implementing the dbus MPRIS standard written in Rust.

jasger commented on 2025-02-10 20:03 (UTC)

@m040601 so I've gone ahead and made a PKGBUILD for the -git and -bin version.
Thanks for the naming suggestions, but I think unless I get a spontaneous epiphany I'll probably stick with the name.
I didn't actually know that there was a package in the main repo, I thought I had looked.

I definitely understand the issue with confusing the file names, however since the package is public, I'm kind of limited as to what I can do about it without introducing breaking changes and making everyone's installs not work anymore.

I'm now going to focus on making a proper man page and an example config.
I currently also have an open pull request for one of my dependencies (https://github.com/dbus2/zbus/pull/1253) which I'd definitely want to include with the next release.

m040601 commented on 2025-02-10 15:01 (UTC) (edited on 2025-02-10 15:05 (UTC) by m040601)

Some more feedback about the logs and desktop. Hope that with enough polish and votes your tool can make it to an official Arch package.

First the logging.

That logging that you, as a developer, want spit to stdout or send to journalctl.

There is already so much stuff there nowadays.

You just want to play a song. And then a giant soup to fish for the really helpfull stuff. Pipewire, Dbus, mpd, alsa, mpris, all dropping stuff into that soup.

So much useless crappy unnecessary by default. Stuff there related to dbus/pipewire, when you have no camera or bluetooth for example. Yes, you can filter/customize/disable this/that, but is only more work for the end user.

Was it an error ? Or was it just not supported ?

Even if the unit is correctly labelled, it is easy as an human to skip the really important stuff you are fishing for.

Then you miss the "mpd" and "mpris" really important messages in that big soup.

Is it a problem caused by the "mpris helper" tool itself ? Or is it a problem with my DBUS ? Or only my python-dbus ? Etc.

I liked that you seem to care about the logs. Keep doing that work.

Make sure to write good informative message sentences, with the uniq tool name inside it. Not just the "unit" name.

Give the user the ability to choose more/less verbose/debug/info output (-v, -vv, -vvv) etc.

Now second about the "desktop".

I know that this dbus/intercommunication/desktop thing must not be easy for a developer.

I actually hate all that polkit, rtkit, xdg-portals, and non essential dbus crap from freedesktop.org. The only one I really find usefull is actually mpris. The idea that is. Not the way it is implemented.

I see a lot of developers lately, making tools too tightly coupled to dbus. Assuming the user has a "full desktop" like KDE or Gnome. With all that polkit/rtkit/dbus crap. Making it impossible to use the tool without installing that crap.

Please dont ever make that mistake as a developer.

I, as an end user, might not be running a desktop. I might not even start X. Or wayland. And I also can play music and use mpd.

m040601 commented on 2025-02-10 14:04 (UTC) (edited on 2025-02-10 15:15 (UTC) by m040601)

Thanks ! Nice to know you care about feedback from end users.

... I couldn't think of a better one,
... I considered mpdris-rs but that would make it seem like mpdris2-rs is a successor to my package 

These are all very valid points.

The thing is everybody wants to stuff the word "mpd" and "mpris" in the name. And everybody forgets that everybody else is also doing the same. It is obvious that the developer himself understands which is his and which is the other.

Apropos. Even I forgot to mention in my previous comment yet another one. You see how easy it is to forget and confuse them ? The one from the japanese guy written in go. |t is an Arch official package.

$ pacman -Qi mpd-mpris

Name            : mpd-mpris
Version         : 0.4.1-2
Description     : An implementation of the MPRIS protocol for MPD
URL             : https://github.com/natsukagami/mpd-mpris
Depends On      : glibc
Optional Deps   : mpd: for connecting to MPD on localhost [installed]
Installed Size  : 4.01 MiB
Packager        : Jakub Klinkovský <lahwaacz@archlinux.org>
Build Date      : Sun 20 Oct 2024 08:48:35 AM WEST

$ pacman -Ql mpd-mpris

mpd-mpris /usr/bin/mpd-mpris
mpd-mpris /usr/lib/systemd/user/mpd-mpris.service
mpd-mpris /usr/share/doc/mpd-mpris/README.md
mpd-mpris /usr/share/licenses/mpd-mpris/LICENSE

Now about the name thing.

... If you have another suggestion please let me know.

I can only give you my perspective as an end user.

It's annoying having things with the similar name to choose from. I want to quickly remember which one is "that good one". Which one uses python ? Rust ? Etc.

Some months later I have another computer or a raspberry to install mpd. Because I dont live in the AUR everyday, I end up forgetting which one was the "good one" and why did , "I", choose it instead of the other one. Because the names are similar, I end up having to do all the "work" again. Checking which github repo is healthy, which PKGBUILD is well maintained on the AUR etc.

My only personal advise is to choose some really unique word. Like a little bit of extra salt or pepper. That makes your tool and PKGBUILD really stand out. BOTH in github AND Aur.

I can understand that you might want the words "mpris" and "mpd" in the name. But I really dont have any good ideas. Out of the blue:

mpdrisrrr
mpdrizrrr

mpdrisr
mpdmprisr

mpdrisrusty

... maybe you dont like hyphens ???

mpdris-rusty
rusty-mpdpris

mpd-mpris-companion-rs
mpd-mpris-helper-rs
mpd-mpris-r

... 

The only thing I know is that when people choose better funny uniq names, I remember better.

Ohhh .. .that "XYZ" is the buggy one from the french guy, that doesnt care about the docs. Forget it. Ohhh .. .that "XYZ" is the bloated electron thing from the chinese guy. Block it. Ohhh .. .that "XYZ" is the go/rust one from the japanese guy. Bookmark it.

The package shouldn't actually conflict with any of the others since
they all use different install paths/directories.

You are correct. Technically this is true. But humanely it is another different story.

I have so much stuff to care about in ~/.config and ~/.config/systemd/user/xyz.service

And then I want to quickly find, edit, configure, start, stop etc.

And cant remember which one was which because of similar names.

Easy to confuse because of single letter "mpdmpris" "mpdris".

Which one is the one with hyphen "mpd-mpris" or "mpdmpris" ?

Inconsistencies in CAPS/minors, sometimes is "d" sometimes is "D" , mpDris/mpdris.

Was that example xyz.service created by me by hand ? Or shipped by the tool.

And then its late you are tired and confuse "mpv-mpris" with "mpd-mpris"

And then you even have the other mpris control tools (not related to mpd) with also confusing names , "mpris-ctl" "mprisctl" etc.

And then people forget to use good "Description" tags on the AUR.

jasger commented on 2025-02-10 11:54 (UTC) (edited on 2025-02-10 12:00 (UTC) by jasger)

Hey, thanks for the comment.

Since you already release precompiled binaries on github, it would be extremelly usefull if you could also provide a "-bin" PKGBUILD on the AUR.

I'll be sure to add a -bin (and -git) version later toady, I kind of forgot to include it.

You should rename this PKGBUILD on the AUR.

I know of the naming problem, however I couldn't think of a better one, which is why I just went with the base name.
I considered mpdris-rs but that would make it seem like mpdris2-rs is a successor to my package even though they're completely unrelated.
If you have another suggestion please let me know.

Make sure if the binary clashes conflicts with others with the same name to use the tag "Conflicts"/"Provides".

The package shouldn't actually conflict with any of the others since they all use different install paths/directories.
If you mean that you can't run them all at the same time, the PKGBUILD wiki entry isn't entirely clear on that.
It writes: "An array of packages that conflict with, or cause problems with the package, if installed."
I interpreted that "if installed" means that runtime is completely irrelevant, hence no conflicts.

Explain in the README why is it different/better than the others.

I mean I'm not really actively competing for users or anything. But if you really want to compare:
My package is as far as I can see basically on par with mpdris2-rs in terms of disk usage (mine's 100KiB smaller, while mpdris2 wins outright 2.11MiB -> 90.73KiB).
RAM is a bit more divided with mpdris2-rs using 5.3MB, mine with 4.1MB and mpdris2 with 39MB.
And performance in terms of speed is basically irrelevant for this kind of application, but I will say that my implementation uses less cloning than mpdris2-rs to expose the data to dbus clients.
The only real standout I have over the other packages is that I manually implement cover searching but that's already detailed in the README.

Provide an example sample.mpdris.conf. You talk about it on the README, but you dont provide one.

Whoops, forgot about that, I had actually planned to make one since I implemented a config.

A final question. I always get these kind of annoying cryptic messages. Never sure if these are errors or can be ignored. Nobody explains in the README's. Everybody assumes the end user is an expert MPRIS/DBUS developer.

You're very likely running a MPRIS client that checks if the TrackList and Playlists interface are exposed/implemented by looking at one of its properties.
So yes, you're correct, nothing to worry about. I'll look into if I can suppress that specific warning since its nothing the user should worry about.

m040601 commented on 2025-02-10 01:45 (UTC) (edited on 2025-02-10 02:10 (UTC) by m040601)

Thanks for this new tool and the PKGBUILD. I'm eager to test this one. I've been testing all others in the AUR for a long time. Not very satisfied.

Since you already release precompiled binaries on github, it would be extremelly usefull if you could also provide a "-bin" PKGBUILD on the AUR. That (binary) release on github should be a tar.gz with the binary, plus LICENCE, README and systemd.service.

Big advice.

You should rename this PKGBUILD on the AUR. Check the AUR naming guidelines. Dont expect your tool is the only one with that name.

Yours:

Name                          : mpdris
Description                   : A MPD client implementing the dbus MPRIS standard
URL                           : https://github.com/jasger9000/mpDris
AUR URL                       : https://aur.archlinux.org/packages/mpdris
Make Deps                     : cargo
First Submitted               : Sun 09 Feb 2025 04:50:32 PM WET
Last Modified                 : Sun 09 Feb 2025 04:50:32 PM WET
Maintainer                    : jasger

There is already another one also in Rust,

Name                          : mpdris2-rs
Description                   : Exposing MPRIS V2.1 D-Bus interface for mpd
URL                           : https://github.com/szclsya/mpdris2-rs
Make Deps                     : cargo
AUR URL                       : https://aur.archlinux.org/packages/mpdris2-rs
First Submitted               : Tue 03 Jan 2023 10:42:27 PM WET
Last Modified                 : Tue 26 Nov 2024 04:55:50 AM WET
Maintainer                    : szclsya

As you can see it is customary to append "-rs" or "-rust" to AUR rust tools.

If you search you will find others even older in python,

aur/mpdris2-git 0.9.1.r0.g09e3371-4 (+1 0.00) (Installed: 0.9.1.r16.g55465b8-1)
    MPRIS2 support for MPD -- git version
aur/mpdris2 0.9.1-1 (+68 0.07)
    MPRIS2 support for MPD

It takes time to distinguish one from the others.

Why not make life simple and not confusing for AUR users searching for tools ?

Dont save characters on the "Description". Say it's written in Rust.

Make sure if the binary clashes conflicts with others with the same name to use the tag "Conflicts"/"Provides".

Explain in the README why is it different/better than the others.

Provide an example sample.mpdris.conf. You talk about it on the README, but you dont provide one.

A final question. I always get these kind of annoying cryptic messages. Never sure if these are errors or can be ignored. Nobody explains in the README's. Everybody assumes the end user is an expert MPRIS/DBUS developer.

could not get properties for active player: GDBus.Error:org.freedesktop.DBus.Error.UnknownInterface: Unknown interface 'org.mpris.MediaPlayer2.TrackList'
could not get properties for active player: GDBus.Error:org.freedesktop.DBus.Error.UnknownInterface: Unknown interface 'org.mpris.MediaPlayer2.Playlists'

My guess is these messages, in your case, just mean that some kind of "functionality" related to Playlists/Tracklist is not yet implemented on your tool.

Am I correct ? Thanks in advance.