Prevent writing settings to global scope for environment and package managers

[eleanorjboyd]

prevents #1468. Now we no longer save env manager or package manage default values to user settings. If a user wants to save these they can but the extension should not as it could very easily cause disruption across a users projects

[Copilot]

Pull request overview

Prevents the extension from persisting environment/package manager defaults into User (global) settings, reducing cross-project interference (addresses issue #1468).

Changes:

• Removed ConfigurationTarget.Global writes for defaultEnvManager and defaultPackageManager in settings helpers.
• Updated unit tests to assert no global-scope writes occur for these settings.
• Documented that the extension avoids writing settings to User scope (with a note referencing #1468).

Show a summary per file

File	Description
src/features/settings/settingHelpers.ts	Removes global-scope persistence for default manager settings.
src/test/features/settings/settingHelpers.unit.test.ts	Updates tests to ensure default manager settings aren’t written to global scope.
docs/managing-python-projects.md	Adds guidance about settings scope behavior and rationale.

Copilot's findings

Comments suppressed due to low confidence (5)

src/test/features/settings/settingHelpers.unit.test.ts:171

• Same issue as above: this test can miss user/global writes if the boolean form (true) is used instead of ConfigurationTarget.Global. Consider asserting that there are zero updates for defaultEnvManager regardless of the third argument shape.

            const envManagerUpdates = updateCalls.filter(
                (c) => c.key === 'defaultEnvManager' && c.target === ConfigurationTarget.Global,
            );
            assert.strictEqual(envManagerUpdates.length, 0, 'Should never write to user/global settings');
        });

src/test/features/settings/settingHelpers.unit.test.ts:192

• Same issue as above: restricting the check to ConfigurationTarget.Global can miss global writes using the boolean form. Consider asserting that defaultPackageManager is never updated when invoked with project: undefined, regardless of target representation.

            const pkgManagerUpdates = updateCalls.filter(
                (c) => c.key === 'defaultPackageManager' && c.target === ConfigurationTarget.Global,
            );
            assert.strictEqual(pkgManagerUpdates.length, 0, 'Should never write to user/global settings');
        });

src/features/settings/settingHelpers.ts:261

• Same as setAllManagerSettings: edits with project unset are filtered out and now become a no-op. To avoid callers accidentally passing “global” edits and thinking they were saved, consider either rejecting/logging those edits or updating the type/docs to remove the “undefined means global” expectation.

        }
    });

    await Promise.all(promises);
}

src/features/settings/settingHelpers.ts:326

• Same concern here: project: undefined edits are filtered out, so callers trying to persist a global package manager selection will get a silent no-op. Consider surfacing that (trace/log/return) or tightening the type contract so it’s clear only workspace(-folder) scoped edits are supported.

        }
    });

    await Promise.all(promises);
}

src/test/features/settings/settingHelpers.unit.test.ts:150

• Same issue as above: checking only for ConfigurationTarget.Global can miss user/global writes if the boolean form (true) is used for the update target. Track the raw target and assert no defaultPackageManager update is attempted in any global form.

            const pkgManagerUpdates = updateCalls.filter(
                (c) => c.key === 'defaultPackageManager' && c.target === ConfigurationTarget.Global,
            );
            assert.strictEqual(pkgManagerUpdates.length, 0, 'Should never write to user/global settings');
        });

• Files reviewed: 3/3 changed files
• Comments generated: 4