Bug: Children Projects in Settings

[eleanorjboyd]

given the project structure:

folderA
    folderB

where folderA is already a python project with envManagerA and pkgManagerA if a user adds folderB as a project with envManagerA and pkgManagerA, do NOT save it to settings.json. This is because folderB is nested inside folderA and has the same env and pkg manager, therefore folderB inherits the correct settings from folderA's configuration by default.

[eleanorjboyd]

One note here is the scenario where folderA is the root of the workspace it will not be listed in the settings.json if it uses default values so it must be inferred as existing and overriding the need for folderB mentioned in settings.json

[eleanorjboyd]

Function to determine if a new project has configurations that needs to be save in settings.json:

1. 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 default pm and em at this time)
2. check if np exists in settings already
3. if it exists and the new settings match, keep the setting as is
4. if it exists and the new setting doesn't match, (we know the new setting has default pm and em so 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 np is 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

[eleanorjboyd]

This function should also consider the multiroot scenario where a given setting will have both path and 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 against np. Also if we save np we need to add the optional workspace attribute to distinguish which root in the workspace it falls under.

[eleanorjboyd]

🤖 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 pythonProjects override; preserve a child override when either manager differs. Include single-root defaults and multi-root workspace+path identity in regression tests. The current add-setting path still appends a new entry without checking inherited manager values. Marking this needs PR.

[eleanorjboyd]

🤖 Closing as not planned for now. I previously proposed skipping the pythonProjects entry 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.