beet not in path in web terminal

[chrishoage]

Describe the bug
Using the v2 rc I navigate to the terminal page. I try to use beet and it is not in the path.

Expected behavior
I expect to be able to use beets for things that beets-flask does not support

What purpose is the terminal for if beet can't be used? Have I misunderstood the purpose of the terminal?

To Reproduce

• go to web ui terminal
• run which beet
• no output

Technical Details
Beet is installed in the. venv for root, but not the beetle user

root@7f76eba81764:/repo# which beet
/repo/backend/.venv/bin/beet

[chrishoage]

I was able to work around it in my startup script

chown beetle:beetle -R /config/beets
chown beetle:beetle -R /config/beets-flask
su -l beetle -c bash -c 'uv tool install beets --with-requirements /config/requirements.txt'

but it feels like this should just already be available to the beetle user

[pSpitzner]

hi @chrishoage,

admittedly, we had a bit of a rough transition to uv :P

We are on it.
Hopefull, this should finally be fixed by #287

[chrishoage]

Looking at the PR I don't think it will. I don't think this is a duplicate python issue it's that uv is installing the bin to /repo/backend/.venv/bin/beet

There are some improvements that could be made to how the docker is set up - and maybe this 2.0 candidate is the right time to introduce a breaking change

I think you may want to consider dropping the "lsio" style AIO docker image, moving out services like redis into the docker compose, and use the USER stanza in Dockerfile to drop privileges before installing the python application with uv

Users who wish to set user id and group id would do so using docker, not env vars.

This just leaves a gap of installing dependencies like chroma, 7z, etc which you would just have to take the hit and bake into the base docker image.

The alternative would be somehow exposing the root venv to the beetle user. You could instead install to /opt/beets-fask/.venv the source it from the beetle user, but there are some questions there around permissions I don't have the answer to with out testing.

Ultimately I think I'll probably end my experiment with beets-flask for now. The idea was promising but not being able to use beets import move is a bit of a final blow for me.

I think I'll probably move to a ttyd container with beets built in, but will check back on this project periodically!

[semohr]

Looking at the PR I don't think it will. I don't think this is a duplicate python issue it's that uv is installing the bin to /repo/backend/.venv/bin/beet

I think pSpitzner may have linked the wrong issue. I actually tested this yesterday in #286 and it behaved as expected.

This just leaves a gap of installing dependencies like chroma, 7z, etc which you would just have to take the hit and bake into the base docker image.

We’ve had this discussion before (see e.g. #50). Our current stance is that we don’t want to ship additional packages that are only required by a small subset of users. Every extra dependency increases maintenance overhead.

At some point we might consider offering an additional "loaded" image tag that includes more optional dependencies, but for now we prefer to keep the base image minimal and avoid shipping things most users won’t need.

Ultimately I think I'll probably end my experiment with beets-flask for now. The idea was promising but not being able to use beets import move is a bit of a final blow for me.

You are using the latest tag. I get your frustration but using the experimental version comes with the cost of it being unstable from time to time. The tmux integration works as expected in the stable 1.2.0 version. There is a reason why we haven't marked the 2.0.0 version as stable yet ;)

I think you may want to consider dropping the "lsio" style AIO docker image, moving out services like redis into the docker compose, and use the USER stanza in Dockerfile to drop privileges before installing the python application with uv
Users who wish to set user id and group id would do so using docker, not env vars.

We did evaluate a setup like that during the migration to the Debian-based container, but ultimately decided against it. In particular, working with ACLs and adding groups turned out to be less straightforward in that approach.

That may very well be a skill issue on our side, but the current setup has been working reliably for us, so further investigation didn’t feel like a good use of time at that point.

That said, we’re absolutely open to improvements. If you have a concrete proposal or PR that demonstrates a cleaner approach, we’d definitely be happy to take a look.

[chrishoage]

You are using the latest tag. I get your frustration but using the experimental version comes with the cost of it being unstable from time to time. The tmux integration works as expected in the stable 1.2.0 version. There is a reason why we haven't marked the 2.0.0 version as stable yet ;)

Oh no sorry this issue has nothing to do with it - I picked the 2.0 version intentionally. The understandable philosophical choice to not support move eliminates 50% of why I use beets. I get the need to support undo but automation is more important.

I do apologize if it was unclear in my message!

We did evaluate a setup like that during the migration to the Debian-based container, but ultimately decided against it. In particular, working with ACLs and adding groups turned out to be less straightforward in that approach.

That may very well be a skill issue on our side, but the current setup has been working reliably for us, so further investigation didn’t feel like a good use of time at that point.

I think it's less a skill issue and more philosophical differences - it would push user id and group id management entirely outside the container. There would be no need to add additional groups to support NFS shares as it is expected the host handles this.

There's nothing inherently "wrong" there - again just philosophical differences about the role of a container.

I think pSpitzner may have linked the wrong issue. I actually tested this yesterday in #286 and it behaved as expected.

Looking at the comments there it is discussing this exact issue - I'll close this issue since it will be fixed by that PR.

No need to add to the noise!

Thank you both for your thoughts and the work on this project! 🙂