-
Notifications
You must be signed in to change notification settings - Fork 10
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: More ways to specify R path #64
Conversation
if (!("acquirePositronApi" in globalThis)) { return; } | ||
if (typeof globalThis.acquirePositronApi !== "function") { return; } | ||
|
||
return globalThis.acquirePositronApi(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just out of curiosity, not asking for a change... Is this all equivalent to globalThis.acquirePositronApi?()
? (Other than you're gracefully dealing with globalThis
not being an object and acquirePositronApi
not being a function, both of which seem unlikely?)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You mean globalThis?.acquirePositronApi()
, right? Then yes, it's equivalent if overly cautious. I'm happy to switch to the cleaner syntax.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmmm, I don't think that's right... I think globalThis?.
checks for globalThis
being null/undefined but not acquirePositronApi
. It looks to me like ?()
is not a thing, I think maybe the original is best.
Or
const apa = globalThis?.acquirePositronApi;
return apa ? apa() : undefined;
Or
if (typeof acquirePositronApi === "function") {
return acquirePositronApi();
}
(Bikeshedding so hard right now... sorry... 😬)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or
globalThis?.acquirePositronApi?.call(globalThis)
(Alright I'm done, I promise!)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think that's right... I think
globalThis?.
checks forglobalThis
being null/undefined but notacquirePositronApi
Oh yeah, that's right. I think this is pretty succinct and brings in the right ideas:
function getPositronAPI(): undefined | any {
if (typeof globalThis?.acquirePositronApi !== "function") { return; }
return globalThis.acquirePositronApi();
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than the one type tweak, LGTM!
Fixes #61
Adds support for consulting the IDE for the preferred R runtime in two ways:
In Positron, we now consult the preffered runtime, i.e. the runtime selected by the user for the project. The extension will follow the prefferred runtime version on launch, meaning that if you launch the app with R 4.4, change to R 4.2, and relaunch the app, the second launch will use R 4.2.
In VS Code, the R Debugger extension includes
r.rpath.{windows,mac,linux}
settings. We also consult this setting. Note that the R Debugger extension should not be used in Positron. We don't skip this check if in Positron (maybe you're syncing settings?), though.The R Path consultation order is now:
r.rpath.{windows,mac,linux}
setting$PATH