-
Notifications
You must be signed in to change notification settings - Fork 349
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
FR: JJ extension suppport #3575
Comments
Note that I am adding Gerrit support in #2845; it has some rough edges still, but I (and several of my colleagues) use it almost every day. I mostly haven't done another round of review yet because I still have 1 or 2 things left to do before the PR is complete (notably adding tests, and documentation for users). I rebase it regularly. Nobody is particularly opposed to it I think, and I believe there is still much interest in adding other specific forge integrations into That said, I have no particular argument against the actual FR here, which is for out of tree extensions that can sit somewhere in the command namespace. Actually, as far as the specific design you suggest, I think exposing most of the Related issue: #3001 — there has also been much more discussion about this over time in various places like Discord, so others should definitely chime in with their thoughts. |
#3034 is also related |
Ah, so the alternative suggested in #3034 would be to define I quite like the fact that with my idea, jj has already started a gRPC server for you, scoped to that specific invocation. This means you don't need to worry about making sure that a long-running daemon is always running, or invoking I think we could also provide optional language support, for example:
And then jj itself would invoke a binary that does something along the lines of (pseudocode):
This would significantly reduce the barrier to entry for an extension, meaning that all you need to do is:
|
There's also #3219 which is along the same line and should be developed along with this. |
Imo we would ideally be able to use extensions for backend implementations as well, maybe one of these crates can help with that: Stabby (a stable rust ABI create) would mean that extensions could only be written in Rust though, while extism would be an embedded wasm runtime which supports a handful of plugin languages. If lua is sufficient as a plugin language, https://github.com/mlua-rs/mlua could also be an option |
If we do need backends to be added without recompiling the binary, then maybe it would be enough to have a single proxy backend that implements the |
This isn't just about new backends, but — I am strongly against an approach leaning on the dynamic linker (stabby) unless we survey the use cases and come to the conclusion that it's absolutely necessary; it brings a very long tail of complications and many supposed benefits do not always materialize in practice on all platforms. extism is more interesting, but I think we'd have to do a lot of work for anything except Rust to be usable anyway (for one, we basically need to write FFI bindings for the jj hostcall APIs for N languages, in order to have anything that is reasonably usable OOTB), and the host<->sandbox bridge implies a lot of other technicalities that are not easy to work around without writing your own crates, anyway. For example, it would probably not be possible to use extism to, say, write a new working copy implementation that used something like FUSE, because the FUSE library would need to be compiled into the host application anyway before you could reasonably expose APIs for it. You end up back at square 1. Realistically I think adding backends/trait impls is far, far less of a pertinent issue for users, so we should only ever cross that bridge when (if) we get to it and there are no other options. |
I'm reading through this discussion from the perspective of wanting to convice people that I noticed that [aliases]
gerrit = ["util", "exec", "--with-grpc-server", "--", "/path/to/gerrit/binary"]
# ^^^^^^^^^^^^^^^^^^^^
# optional, to be discussed |
Is your feature request related to a problem? Please describe.
I'm trying to make a
jj gerrit
subcommand which will support gerrit. I imagine that people will make commands likejj github
,jj lint
,jj fix
.Describe the solution you'd like
Not so much what I'd like - I'm not particularly attached to the idea and welcome other ideas, but my thoughts were:
Running
jj gerrit foo bar
would:/path/to/gerrit/binary gerrit foo bar
with the environment variablesJJ_SERVER=fd:3
The subprocess would then:
JJ_SERVER
to get the specifications for the grpc channel and create a grpc connection over these.Describe alternatives you've considered
Additional context
Add any other context or screenshots about the feature request here.
The text was updated successfully, but these errors were encountered: