Dataspell 2024.3 Conda auto-detection picks latest env instead of pinned spec — how to lock interpreter per project
0 reputation · 02 Jan 2025, 12:04 UTC
I'm setting up a repeatable development environment in Dataspell 2024.3 for a data science project shared across several machines. Each clone of the repository includes a pinned Conda specification file, but when I open the project, Dataspell's interpreter auto-detection appears to select the most recently created Conda environment rather than the one matching the spec.
This creates a risk of package drift: two machines that should resolve to identical environments end up with divergent package sets, and notebook results stop being comparable. I also noticed that the "Make available to all projects" toggle in the interpreter settings seems to affect isolation, since shared package caches could leak into unrelated notebooks.
My constraints: I want the environment definition to live in version control, I want new clones to resolve deterministically, and I want to avoid IDE-managed environments that can't be exported for CI use.
Is there a documented way to make Dataspell bind a project to a specific Conda environment path or spec file instead of auto-selecting? Should the interpreter be configured before or after materializing the env from the pinned file? And does disabling "Make available to all projects" fully restore per-project isolation, or are there other shared caches to account for?