-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Improve devcontainer experience, particularly when switching from pip to uv. #12197
Comments
Same for here! |
@juanjcardona13 could you please provide more details? that sounds like a different thing? |
First of all, we can definitely create an integration guide for this. Thanks for flagging some of the things you'd want to see there. I gave your example a quick try, and If you're opposed to using a virtual environment since it adds indirection, then you can change to the root user Generally, I'd recommend using our top-level interface, e.g., |
I think it would be great to have a resource to link for people. As availability allows, I'm happy to help draft a bit and/or test. I edited that line to
I think things like this are why some devcontainer users really dislike the required venv. There's also the beginner/student case, which is more specific to some of what I do, but it also got some discussion in the other threads. I used to use conda, and I had to set aside an hour in a workshop to troubleshoot, and, in bad cases, troubleshoot during breaks or after hours. When I switched to devcontainers (and recommended using Codespaces), that dropped basically to zero. Personally, I don't like the root idea. It runs against this VSCode documentation suggestion, and I'm also not sure I can fully identify and mitigate the security implications for me and for wherever a devcontainer might end up (other devs, students, clients). I'm definitely interested in the top level interface for new projects and modifying projects where uv has been added. At the moment, I'm just more focused on the switching case. I suspect that I'd rather not spend a few years with both setups, rather than spending what I hope is a small amount of time migrating everything to uv once the problem space and procedure become clear. Edit: Forgot that Github doesn't ignore newlines in markdown paragraphs. |
For most of those problems, it just sounds like you need to put the virtual environment at the front of your
I actually don't see a recommendation not to use the root user there? It just explains how to do so. I agree it's nice not to use the root user, but.. you're also trying to write to global state which the author of the images have decided should require root permissions. It looks like just using
|
Here's a more complete example using a virtual environment
|
(Started writing this before the most recent replies.) I spotted another issue that seems to be a venv issue. After I wrote the previous part up, I noticed that Onedrive was syncing a lot of data. And, I could see in the filenames that it looked like a lot of package internals. So, I created a second copy of the devcontainer configuration and the notebook/data I'm working with.
It appears that the stock Python devcontainer image uses caching to store a lot of the devcontainer packages, so none of that hits the workspace that is linked into the container from the host filesystem. In contrast, the uv venv is all in the I poked around and didn't quite see explicitly how the caching works, but it may use the vscode docker volume that's mounted across containers. The top of the rabbit hole I went down is the Python image source. There are some environment variables in the container that may be relevant, but I don't know enough about those internals to be sure. |
Here's a link to the section that says:
For now, I wanted to point that out, and I'll test out the other things you posted. Thanks again for all of your help. |
I agree using a non-root user in production makes sense. I'm not sure if I'd go out of my way to do so in a development container. Regardless, we should support it.
Interesting... we'll need to look into that. I wonder if that's why we get a link-mode warning. I'm sure we can setup a shared uv cache. |
Summary
I tried changing an existing devcontainer to use
uv
instead ofpip
, and I ran into the error mentioned in ##11599.Initial devcontainer.json with only uv added:
requirements.txt:
When I change
postCreateCommand
to use uv like this"postCreateCommand": "uv pip install -r .devcontainer/requirements.txt"
, I get this:When I then add
--system
to get"postCreateCommand": "uv pip install --system -r .devcontainer/requirements.txt"
, I get another error:Example
Ideally, a user could simply add a
uv
feature to a devcontainer, change thepostCreateCommand
to useuv pip
instead ofpip
, and have it work.More broadly, it would be nice to see worked examples of how uv works nicely with devcontainers. Among other things, I work with beginners (other PhD researchers), and I build a devcontainer for the course I teach (and use them extensively in my own projects, both academic and external). It would be nice to see uv work well throughout the lifecycle of a project:
pip install
the needed packages, let it solve,pip freeze
, and use that output to pin only the versions of the key packages (intended to be a portability habit). Then I rebuild again and work.pytest
), and keep/rollback the update? I usually teach apip freeze
approach, but the docs make it look potentially much easier with uv.I think it would be great if uv had a devcontainer feature that simply handled all of the venv,
--target
, and other differences for users. In a devcontainer, there's generally just one Python install that matters, and that'susr/local/bin/python
, which I think is the root of a lot of the previous discussion about--user
.The text was updated successfully, but these errors were encountered: