Install without Docker, or manage seperate libraries

[cfilipov]

I have separate music libraries for my main music and classical music with very different beets and beets-flask configs.

Supporting multiple libraries in one container would be nice. Or being able to install directly without docker and run multiple instances on one machine would work too.

Right now I'm using two separate docker containers which is quite heavy.

[semohr]

This is sadly not as straightforward as it sounds. Especially the frontend will break significantly, or require a substantial refactor, if we allow multiple beets databases. We are working on an overlay system that allows defining different plugin configurations per inbox, but fully supporting multiple libraries isn’t really feasible.

It’s also somewhat against the spirit of having a single database for all your music, which is what beets is really designed around.

Running without a container should be possible: you would need to build the frontend and run the Python server manually. You can take a look at our entrypoint.sh and Dockerfile to get an idea of what’s needed to set up and run Beets/Beets-Flask directly on your machine. However, we won’t provide detailed instructions for this, as it’s not intended to be a main use case.

[pSpitzner]

This is sadly not as straightforward as it sounds. Especially the frontend will break significantly, or require a substantial refactor, if we allow multiple beets databases. We are working on an overlay system that allows defining different plugin configurations per inbox, but fully supporting multiple libraries isn’t really feasible.

It’s also somewhat against the spirit of having a single database for all your music, which is what beets is really designed around.

Running without a container should be possible: you would need to build the frontend and run the Python server manually. You can take a look at our entrypoint.sh and Dockerfile to get an idea of what’s needed to set up and run Beets/Beets-Flask directly on your machine. However, we won’t provide detailed instructions for this, as it’s not intended to be a main use case.

+1

Related thought: We should look into why the containers are "heavy". For running two instances, resouces should not become a concern. Related: #244
We can get to that once v2 with the switch to debian is out.
@cfilipov if you want to investigate this a bit, a good starting point imho would be to re-evaluate if we need the multiple uvicorn workers. In any case, this should become a configurable env var.

[cfilipov]

For classical music, the tagging rules are different and the metadata also ends up polluting the main music library making harder to navigate by artist or album artist. So far the best approach I've see so far is to keep them separate, what are other people doing?

For now I will continue to just run two containers as that seems like the path of least resistance.

As far as the containers being heavy, right now each container I'm running takes about 800mb ram. The images are about 500 mb each which is not bad, but based on #212 am I to understand this is moving to debian? That would make the images larger too (btw I think that is a worthy tradeoff, making it easier to deal with plugin is worth the larger image size imo).