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.