Repository navigation
Bug: Children Projects in Settings #401
Description
Activity
One note here is the scenario where
folderAis the root of the workspace it will not be listed in thesettings.jsonif it uses default values so it must be inferred as existing and overriding the need forfolderBmentioned insettings.jsonFunction to determine if a new project has configurations that needs to be save in
settings.json:- check if the newProject (lets call
np) has default pkgManager (pm) and envManager (em). (This will ALWAYS be true at this point in time since the New Project flow only supports defaultpmandemat this time) - check if
npexists in settings already - if it exists and the new settings match, keep the setting as is
- if it exists and the new setting doesn't match, (we know the new setting has default
pmandemso only save if it is a unique setting from its parent.- To check if a setting is unique from its parent, go through all other existing settings, check to see if
npis a child of a given URI in the settings - Then check if the setting found as a parent has the default (which means it matches the
np) and if so don't add it
- To check if a setting is unique from its parent, go through all other existing settings, check to see if
- check if the newProject (lets call
This function should also consider the multiroot scenario where a given setting will have both
pathand workspace that can be combine to represent its URI. For each setting, the URI will have to be built from these components to then be checked againstnp. Also if we savenpwe need to add the optionalworkspaceattribute to distinguish which root in the workspace it falls under.🤖 Triage: the issue and follow-up comments give a concrete fix plan. When adding a nested Python project, compare its effective environment/package managers with the nearest parent project and avoid writing a redundant
pythonProjectsoverride; preserve a child override when either manager differs. Include single-root defaults and multi-rootworkspace+pathidentity in regression tests. The current add-setting path still appends a new entry without checking inherited manager values. Marking thisneeds PR.- linked a pull request that will close this issueAvoid redundant settings for nested Python projects #1815
on Sep 24, 2026 🤖 Closing as not planned for now. I previously proposed skipping the
pythonProjectsentry when a child uses the same managers as its parent, but that entry also records that the child is an explicitly added project. Without it, the project can disappear after reload, and removing an existing entry could override a user’s deliberate configuration (including a choice to pin managers even if a parent changes). The current runtime also does not inherit managers from the nearest parent. Preserving the user’s explicit project setup is more important than avoiding this settings entry. If we want a separate “inherit managers” behavior later, we should design how project identity and explicit-versus-inherited settings are represented first.
given the project structure:
where
folderAis already a python project withenvManagerAandpkgManagerAif a user addsfolderBas a project withenvManagerAandpkgManagerA, do NOT save it to settings.json. This is becausefolderBis nested insidefolderAand has the same env and pkg manager, thereforefolderBinherits the correct settings fromfolderA's configuration by default.