pyproject.toml subtlety in DevContainer

I pretty much start every Python project with a pyproject.toml. It keeps things simple: - One place for configs - Easy for VSCode to pick up - Easy to reuse in CI/CD pipelines - No environment variables to set up - No manual setup for installs and dependencies But I ran into a subtle issue while using it inside a DevContainer. Everything looked fine: - Project structured correctly - pyproject.toml in place - Virtual environment set up But imports started behaving inconsistently. What made it tricky was that nothing was obviously broken. So I went back to basics:   - checking where Python was actually importing from import my_package print(my_package.__file__) That’s when it clicked. The DevContainer was picking up a previously installed version of the project instead of my current code. The fix ended up being:   - installing the project in editable mode pip install -e . After that, imports consistently pointed to the working directory instead of a stale installed version. Big takeaway for me: Even with a clean pyproject.toml, how your project is installed matters just as much as how it’s defined. Lately I’ve been focusing more on making my dev environment predictable, not just “working” Curious how others handle this: Do you always install your project in editable mode during development? #DevOps #Python #Docker #VSCode #SoftwareEngineering

To view or add a comment, sign in

Explore content categories