Optional Python and R attributes within configuration file

[sagerb]

…n sections and filling in of defaults when deploying. Also added new types and new unit tests.

Intent

The changes within this PR support the initialization of config files to have default attributes associated with R and Python dependencies, allowing the sections to be empty within the config file. When values are present, they are used by the back end, but when they are not present, the current values from the active interpreters are used, as the deployment manifest is built from the config file.

Resolves #2468
Resolves #2470

Type of Change

• • Bug Fix
• • New Feature
• • Breaking Change
• • Documentation
• • Refactor
• • Tooling

Approach

This is the second attempt to implement this functionality, with the previous one being closed without merging (#2568). I have simplified the approach within this PR and believe it is significantly addresses the concerns voiced during the previous PR's review.

The schema has been updated to allow all of the attributes present within the R and Python sections of the configuration to be optional. The presence of the section ([r] or [python]) has been maintained as the indicator that the deployment has a dependency on the particular interpreter.

Queries of a Configuration maintains its values as persisted. Empty attributes indicate that defaults will be applied.

The queries from the extension will return the configuration objects with empty attributes where defaults are expected. Because the extension relies upon having the attributes resolved (either from values present within the file or from the current default values determined by the active interpreter), the extension now calls a new API to get the default values from the active interpreters (GET /api/interpreters) and resolves the defaults within each configuration object prior to updating its state (store).

When a deployment is initiated, the agent resolves the defaults in the configuration file before generating the manifest file from it.

To remove any potential errors when passing in an R interpreter path vs. a Python interpreter path, I created a typescript type for each. This way I was able to get compilation errors rather than catching the coding issues during unit tests.

User Impact

New feature: The scenario goes like this:

1. A publisher has created a deployment that uses their currently active R and/or Python interpreters as the versions requested in the manifest.
2. The next day, they upgrade or change their active interpreters and then deploy again. These re-deployments once again request the active R and/or Python interpreters within the manifest.
3. If at any point the user sets the attribute values within the R or Python section, they will be used rather than floating to the active interpreter values.

Automated Tests

Unit tests were added and modified for the new functionality.

Directions for Reviewers

The important changes in order are:

1. Schema Changes making the attributes optional
   • internal/schema/schemas/posit-publishing-schema-v3.json
   • internal/schema/schemas/draft/posit-publishing-schema-v3.json
2. Addition of Interpreters
   • internal/interpreters/python_mock.go
   • internal/interpreters/python_test.go
   • internal/interpreters/python.go
   • internal/interpreters/r_mock.go
   • internal/interpreters/r_test.go
   • internal/interpreters/r.go
3. Addition of Get Interpreters API
   • internal/services/api/get_interpreters_test.go
   • internal/services/api/get_interpreters.go
4. Use of the new API and proper passing of the active interpreters into a few calls
   • extensions/vscode/src/api/resources/Configurations.ts
   • extensions/vscode/src/api/resources/ContentRecords.ts
   • extensions/vscode/src/api/resources/Interpreters.ts
   • extensions/vscode/src/api/resources/Packages.ts
   • extensions/vscode/src/api/types/configurations.ts
   • extensions/vscode/src/api/types/interpreters.ts
5. Filling in default values when configurations are queried and stored into the extension's state
   • extensions/vscode/src/state.ts
6. Filling in default values as part of the deployment process
   • internal/state/state.go
   • internal/state/state_test.go
     The rest of the file updates are swaps to the new TS Types or signature changes.

Checklist

• I have updated CHANGELOG.md to cover notable changes.

[marcosnav]

Still reviewing, but I already have some comments that you might want to take a look...

[marcosnav]

Ditto here about interfaces and pointers, generally this isn't needed and complicates things.

Same applies for some other files with *interpreters.RInterpreter and *interpreters.PythonInterpreter.

[sagerb]

The code and tests have been reworked. Thanks.

[marcosnav]

@sagerb This PR looks much better than the last one, let me know when it is ready for another look.

[tdstein]

I reviewed the Go code and everything seems correct. I tried out a local installation and was able to publish to Connect successfully.

It looks like some ui-tests need to be updated, but otherwise I think this is ready to merge.

[marcosnav]

Getting back to this one and for clarity. The use of pointers on interfaces should be removed.

[sagerb]

@marcosnav I've pushed changes that should address all of your concerns. Thanks so much for the feedback. Can you re-review?