it's a little chunky, but here's a version with more origin info:
This looks reasonable. I think you should maybe talk to @alangenfeld and @dgibson quick about supporting gprc location types. It might change the structure pretty substantially so might want to just do it now.
Also in the case where the executable is the same executable as the one that is hosting dagit should we omit it? Might be cleaner
why function and not attribute?
I think it would be good to make this a re-usable little component then you could replace the current call site of codePointerDescription with it. I am working on a instance level schedule page that could use it too
yeah, this is timely since I just introduced a base RepositoryOrigin and new subclass in D3975.
I had been planning to possibly remove executable_path and the code pointer stuff from the repos running in GRPC servers, in place of just an identifier for the repo, but knowing that we may want to still surface that information in dagit means I should probably not do that.
we should imagine a world someday where these specific keys aren't set for every repo.
Might be overkill while everything's still in python, but we could also consider allowing the repos to supply key-value metadata pairs for this on the server rather than assuming a specific structure on the client?
will this error out if you call it on a repo with a GrpcServer origin rather than a Python origin?
There should be some dagster-graphql test coverage that includes those types of origins now (for example sqlite_instance_external_grpc_server_env), not sure if it goes through this specific codepath though
This looks good but I think I agree with @dgibson's comment above - exposing a set of arbitrary key-value pairs specific to the pointer type and rendering them seems like it might be more flexible than coercing these different pieces of data into "value" and "attribute"? I wouldn't particularly expect "attribute" to be a function name but admittedly I am not a python developer.
Other than that this looks great though! The UI is indeed slightly chunky but we can tweak it as we go and if people start adding more than a few repositories.
This looks great to me 👍 I feel like the metadata approach gives this a lot of flexibility and the code looks clean. I think we can tweak the visual appearance a bit but the ideal styling sort of depends on how many options end up appearing in that menu in the common case, so it might be best to wait and see how this gets used!