Note linuxserver.io in getting started - #4859
Conversation
sampsyo
left a comment
sampsyo
left a comment
There was a problem hiding this comment.
Great; thanks for getting this started! I have a suggestion to make things even clearer based on your information.
| * On **containers** (Docker-compatible), there is an **unmaintained** | ||
| install via Linuxserver.io. This can cause some | ||
| `compatibility issues <https://github.com/beetbox/beets/issues/4838>`__ | ||
| and you should at least | ||
| `change the config <https://github.com/linuxserver/docker-beets/issues/94>`__ | ||
| to match the beets default. See `Configuring`_, below. |
There was a problem hiding this comment.
How about this wording, to make the context even more obvious?
Some users want to run beets is a Docker container. We don't (yet) have an official Docker image, and one popular image from LinuxServer overrides the default configuration in a way that may be confusing. We recommend using a different image, or [etc.].
And maybe this should be last in the list, so it looks less like we are endorsing this as one of the main ways to use beets?
Maybe this is an argument that we should provide an official container someday…
There was a problem hiding this comment.
Once this PR is in I was going to shuffle around the "getting started" section as part of our user acquisition funnel. I think Windows (brief message to look below), Mac, Ubuntu, containers? should be at the top. The other OSs probably don't need top billing.
I was trying to keep it short and sweet - users need to know they may want to change the config, we don't need to say why.
On Docker **containers** there is an **unmaintained**
install via Linuxserver.io. The default configuration has been changed
in this install, which can be `confusing <https://github.com/beetbox/beets/issues/4838>`__.
You may want to `change the config <https://github.com/linuxserver/docker-beets/issues/94>`__
to match the beets default. See `Configuring`_, below.
What other container? That's a losing battle, Linuxserver seems to be very popular. And I don't want to link to some 3-user container that will be unsupported and busted in 6 months. LSIO isn't supporting this container, but the upstream Linux (alpine?) should at least be getting security updates.
There was a problem hiding this comment.
Also, I have a suspicion that this container is the #1 way people use beets. Seems like a lot of people use it in a headless, set-and-forget manner. Just brute force auto matching to whatever's closest on Musicbrainz and moving on.
There was a problem hiding this comment.
Sure; good point—probably no sense in recommending "use another container" if we know of no good ones!
There was a problem hiding this comment.
Maybe this is an argument that we should provide an official container someday…
I used to use beets 'directly' but had ongoing issues across years maintaining an up to date, stable system - constant conflicts with other python libraries etc. I know there are ways around the things, but there was definitely 'rot' setting in on numerous occasions and it became quite frustrating.
Combined with e.g. the state of ReplayGain support (different tools coming and going, neo Nazi infestation etc) - I pretty much gave up on beets for a while...until I discovered the LinuxServer container.
At the moment, I do use it as described above, basically - as a brute force processor (and I think that's their intention, really, hence the changed config you're talking about - basically, in this context, it is a tool to take in sundry input and spit out pretty reliable, fixed up output. But of course it would be great to have a container/containers that support the classic manage-the-whole library approach.
But if the question is 'should we have an official docker of this' - then I'd argue beets is exactly the sort of application that would benefit hugely from having one. The docker approach means you an create an 'ideal target' where everything is standardised, and you'll have far more control over delivering a stable, reliable working version of beets. And docker is everywhere these days, and hugely popular, with media and media processing tools - many people run their ffmpegs and what have you as docker tools rather than as local installs, because this has proved a lot more robust (and once set up, with an alias, you can basically not even tell it's using a docker version).
If you look at e.g. the case of Logitech Media Server - a somewhat related app at least - there were a number of unofficial dockers floating about, but those never really achieved mass traction and were unreliable in terms of updates etc. Once they announced they were going to make an 'official' docker (inasmuch as a software system for basically dead hardware can have an 'official' anything!) - the community coalesced around that, helped with the development and testing, and in a short term it pretty much has become the de-facto way of running LMS.
LinuxServer is kind of erratic with their stuff, as can be seen here. Whilst obviously there's an initial development price for in-housing this, I suspect there would be a lot of long term benefit to it.
There was a problem hiding this comment.
Yeah, this is a pretty strong argument for putting together our own Dockerfile and publishing some official images!
There was a problem hiding this comment.
I would gladly use a docker image, but I don't think I have any interest in maintaining one for the community. Our maintainers are stretched super thin and I don't know who would step up to maintain one. Maybe a nice message to LinuxServer.io can lead to a productive partnership? Over on Discourse, I'm documenting my process running linuxserver.io container on ARM. I hope this is my last and final beets resting place. https://discourse.beets.io/t/diary-of-beets-on-arm-odroid-hc4-armbian/1993
There was a problem hiding this comment.
I think calling it a compatibility issue is some seriously loaded language. Should just be left at something like "Third party containers may have a non-default config, verify options before running" There's nothing that makes copy over move more 'correct'
There was a problem hiding this comment.
@OverlordQ what about
On Docker **containers** there is an **unmaintained**
install via Linuxserver.io. The default configuration has been changed
in this install, which can be `confusing <https://github.com/beetbox/beets/issues/4838>`__.
You may want to `change the config <https://github.com/linuxserver/docker-beets/issues/94>`__
to match the beets default. See `Configuring`_, below.
|
Unmaintained also now seems slightly unfair to be honest, considering e.g: ...it's perhaps slow to be maintained, but they have both a working stable 'latest' based on the last beets release (which I believe is very old at this point) - and a working 'nightly' based on, well, nightly code (which I think is the one most people use in practise). |
|
There is no communication between our project and LSIO which seems incredibly unhealthy. linuxserver/docker-beets#94 |
|
Well what type of communication are you needing? All it's doing is bundling upstream into a container. The last beets release was almost two years ago. |
|
They modified the beets config without explanation, and when asked, they have not responded. Users express confusion over the changes that were made. |
|
It's not some massive leap though, with this sort of media tool, is it? Copy vs. move? Sure that one video guy has his ideas on it, but...I suspect a whole host of people use this container and don't mind that change, and it's trivial to change back to copy should you wish to. The LinuxServer docs are - across the board - pretty terrible though, for sure. Usually there are actually better guides but they are kinda hidden away in other spots, usually not even linked off their dockerhub pages etc. Case in point, I suspect the vast bulk of people using this container will have found and started with this: ...which does explain that is uses move as opposed to copy. I suspect in terms of contact, it's one of those 'make a PR and submit to the repo' to get a response kind of scenarios. |
|
Is this still relevant? If so, what is blocking it? Is there anything you can do to help move it forward? This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
I think this should be closed or at least altered. The Linuxserver docker is used by a lot of folks and is not unmaintained - it might be slower than desired, but a lot of us have been using it successfully for a long time. The config warning part of it might make sense still, although I don't think it's a huge issue for anyone at the level of using a docker container for this sort of thing, so just a quick note pointing out the change from default would be all that is needed IMO. |
|
The configuration has been adjusted in linuxserver/docker-beets#112 to match ours so I'm closing this |
5 participants
Description
Fixes #4838.
(...)
To Do
docs/to describe it.)docs/changelog.rstnear the top of the document.)