You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We should update how we decide which R version we specify for running on Connect. This work would update the the R.version field in the config to be optional, and document what it means to set it. This should also update how we build the manifest.json accordingly:
From the R.version in the config, if set (this field is now optional)
From the current active version of R in the IDE, if the R.version is not set in config
The answer to this should populate the platform field in the manifest.json, when we build it.
Note that this doesn't lean on the R version defined in renv.lock, which, ultimately, we may want to do. If we tackle that change, it will be in a follow-on issue.
After analyzing feedback from the original PR that was created to address this issue (#2568), we've decided that the alternative design which was informally discussed would be a better direction to go in.
With the implementation of default values, for R and Python, derived from the active interpreters at the time of deployment, the challenge has been how to keep the concept of a default wanted vs. a locked-in (supplied) value within the extension UX, which depends on values for these fields.
The attributes / responsibility of this alternative design would involve maintaining the internal representation of the configuration objects as they are represented on disk, with the addition of default value fields. The deployment process (in the agent) would be responsible for resolving the defaults, at the time needed when generating the maniftest. The extension UX would be responsible for converting the configuration objects queried from the agent w/ the active "expected" default values.
Current thoughts on this path: the configuration object can can be extended to include default values inserted during transit. This would maintain being able to identify the difference, but would make the users of this field responsible for looking possibly at both values. (However, this can be done within the existing store, with an explicit computed value.)
The text was updated successfully, but these errors were encountered:
We should update how we decide which R version we specify for running on Connect. This work would update the the
R.version
field in the config to be optional, and document what it means to set it. This should also update how we build themanifest.json
accordingly:R.version
in the config, if set (this field is now optional)R.version
is not set in configThe answer to this should populate the
platform
field in themanifest.json
, when we build it.Note that this doesn't lean on the R version defined in
renv.lock
, which, ultimately, we may want to do. If we tackle that change, it will be in a follow-on issue.After analyzing feedback from the original PR that was created to address this issue (#2568), we've decided that the alternative design which was informally discussed would be a better direction to go in.
With the implementation of default values, for R and Python, derived from the active interpreters at the time of deployment, the challenge has been how to keep the concept of a default wanted vs. a locked-in (supplied) value within the extension UX, which depends on values for these fields.
The attributes / responsibility of this alternative design would involve maintaining the internal representation of the configuration objects as they are represented on disk, with the addition of default value fields. The deployment process (in the agent) would be responsible for resolving the defaults, at the time needed when generating the maniftest. The extension UX would be responsible for converting the configuration objects queried from the agent w/ the active "expected" default values.
Current thoughts on this path: the configuration object can can be extended to include default values inserted during transit. This would maintain being able to identify the difference, but would make the users of this field responsible for looking possibly at both values. (However, this can be done within the existing store, with an explicit computed value.)
The text was updated successfully, but these errors were encountered: