Remote library client

[sampsyo]

trafficstars

This is a subtask of the next-generation web interface effort (#718).

As the new HTTP API (#736) evolves, it would be useful to start designing a command-line client for the API. Ideally, it would be possible to run some familiar beets commands (beet ls, etc.) against a remote library that's running a server.

In addition to being cool and useful, this will help us make the API "complete" in the sense that local operations have a remote equivalent.

[heylookltsme]

Any chance this is still on the roadmap? My library is on a raspberry pi and I'd love to quickly run beet queries locally without needing to ssh into the pi. 👍🏻

[wisp3rwind]

I don't think anybody has been working on this — sorry! If someone would step up to do the work, this idea could of course be picked up.

As a stop-gap solution, you might be able to avoid the explicit ssh by something along the lines of

# In .bashrc or similar
alias beet-pi='ssh <my-raspberry-pi> beet'

# Then run (I haven't tested this!)
beet-pi ls foo

i.e. have ssh execute beets directly instead of dropping you into a shell, and use a shell alias to make that convenient?

[heylookltsme]

I just tested that and it does indeed work! i would not have expected it to be so easy. 😅 Thanks very much!

[catap]

Thus, this can be implemented partially with quite trivial changes via https://pypi.org/project/sshfs/ that seems allows to simple define library as ssh://host/path in config.

I'll try to do it today, and if it as simple as it seems will open PR

[Kernald]

Sorry to be a buzzkill, but I'm not sure supporting a ssh://host/path location for the library solves this problem:

• A sshfs mount can arguably already be mounted easily through fstab/other means, with more options (smb, nfs...) available as well. This is hardly beet's responsibility.
• sshfs isn't a silver bullet here - if one's SSH key requires a password, the experience will be less than ideal.
• The more important part: paths are stored in absolute in the database, as far as I know. Meaning that both the local machine and the one containing the database must have the music files available in the same location.

I'm not really sure what the vision for #736 is today as these bugs are quite old, but an API would be quite more flexible than sshfs.

[catap]

• A sshfs mount can arguably already be mounted easily through fstab/other means, with more options (smb, nfs...) available as well. This is hardly beet's responsibility.

Well, here the catch: /etc/fstab defines system level mount and this way you'll have to care about permission on the system. Special with NFS. Special with NFS before v4. Ok, with v4 you still need to kare about kerberos and other non trivial and not so stable stuff.

Which can be solved the proper way with FUSE, but it kind a night mare.

• sshfs isn't a silver bullet here - if one's SSH key requires a password, the experience will be less than ideal.

Sure, no sivler bullet here.

I'm not really sure what the vision for #736 is today as these bugs are quite old, but an API would be quite more flexible than sshfs.

Not always.

For example I host my library on Synolog NAS and use its mobile app to stream on phone.

and installing additional software (beets) to the synology isn't trivial task.

But control library via different mount points works quite nice for couple of years :)