Initial API proposal for Ruby Environments extension #9
Conversation
rafaelfranca
force-pushed
the
rmf-initial-implementation
branch
4 times, most recently
from
40de55e to
0cba52b
Compare
src/status.ts
Outdated
| this.item.severity = vscode.LanguageStatusSeverity.Error; | ||
| } else { | ||
| const version = rubyDefinition.rubyVersion; | ||
| const yjitStatus = rubyDefinition.yjitEnabled ? " (YJIT)" : ""; |
There was a problem hiding this comment.
Thinking ahead: Should we make this into enabledJIT field with an enum value of YJIT and ZJIT instead of a boolean flag for YJIT only?
There was a problem hiding this comment.
Totally. I'll do that.
There was a problem hiding this comment.
Actually, the yjitEnabled field is supposed to go away because on Ruby >=3.3, we enable YJIT automatically from the server with RubyVM::YJIT.enable.
Unless ZJIT won't offer the same thing, we should in fact remove this field completely now that 3.2 is EOL.
There was a problem hiding this comment.
Regardless, the Ruby you are running on might not be compiled with a JIT, though, so I think it is still worthwhile information to display if your Ruby is running with a JIT enabled or not.
There was a problem hiding this comment.
Yeah, that is more Availabe JITs than Enabled JITs. I renamed.
src/status.ts
Outdated
| this.item.severity = vscode.LanguageStatusSeverity.Error; | ||
| } else { | ||
| const version = rubyDefinition.rubyVersion; | ||
| const yjitStatus = rubyDefinition.yjitEnabled ? " (YJIT)" : ""; |
There was a problem hiding this comment.
Actually, the yjitEnabled field is supposed to go away because on Ruby >=3.3, we enable YJIT automatically from the server with RubyVM::YJIT.enable.
Unless ZJIT won't offer the same thing, we should in fact remove this field completely now that 3.2 is EOL.
vinistock
left a comment
vinistock
left a comment
There was a problem hiding this comment.
What do you think about breaking this down into smaller chunks? If we have bandwidth to design the API, let's do it step by step and make sure we avoid shortcomings of the current implementation.
For example:
- Better callbacks for when re-activation will happen
- Better ways to handle error scenarios gracefully (one of the biggest pain points of the LSP)
- Clearer status communication about degraded status or what caused failures to help users debug their setup
I think it will be easier if we discuss each step one by one
rafaelfranca
force-pushed
the
rmf-initial-implementation
branch
from
7c41bad to
a00ef35
Compare
This stack of pull requests is managed by Graphite. Learn more about stacking. |
rafaelfranca
force-pushed
the
rmf-initial-implementation
branch
from
a00ef35 to
b57951c
Compare
rafaelfranca
force-pushed
the
rmf-initial-implementation
branch
from
b57951c to
71bf6b2
Compare
rafaelfranca
changed the title
|
Done. I broke the PR in multiple stacks. This is the API proposal now |
3 participants
Summary
This PR proposes the initial API design for the Ruby Environments VS Code extension. The goal is to establish the public interface that other extensions (like Ruby LSP) will use to obtain activated Ruby environments.
This is an API proposal focused on design and discussion—not a full feature implementation. The actual version manager integrations and environment detection logic will be added in subsequent PRs.
Proposed Public API
activate(workspace): Request Ruby environment activation for a specific workspacegetRuby(): Retrieve the current Ruby definition (success or error state)onDidRubyChange: Event to subscribe to Ruby environment changesType Definitions
RubyEnvironment: Represents a successfully activated Ruby (version, JIT compilers, env vars, gem paths)RubyError: Represents a failed activationRubyDefinition: Union type for success/error statesRubyChangeEvent: Event payload for environment changesJitType: Enum for supported JIT compilers (YJIT, ZJIT)Next Steps
Once the API design is agreed upon: