Show HN: Graft – Your local environment, everywhere(graft.run)
graft.run
Show HN: Graft – Your local environment, everywhere
https://graft.run
After a few years of development, I'm finally ready to show off an alpha version of graft! My goal was to get my local environment, terminal, ide, and preferences on any machine I connect to. I've set everything up the way I like locally, so why should it get muddied by an ssh/docker session? Graft solves this by transparently synchronizing files, comamnds, and open ports. There's a lot of work to do but maybe someone else can benefit from it now!
2 comments
Cool project! How do language servers work with this system? Suppose I am developing PyTorch+cuda code on a remote machine, do I need to have that same PyTorch version installed locally?
If you run the language server remotely, how do you sync the file before it has been saved so that the user gets autocomplete?
If you run the language server remotely, how do you sync the file before it has been saved so that the user gets autocomplete?
Good question. To quickly answer, no you don't need it installed locally but you will benefit from having the source available.
Just so we have a common reference, look at https://github.com/edaniels/graft/blob/main/pkg/local_client.... The main idea is that we are always matching the local current working directory to the corresponding synchronization directory. Using that idea, we serve an LSP locally that rewrites all json-rpc messages that utilize URIs (https://github.com/edaniels/graft/blob/main/pkg/local_client...) from local to remote, and back. The local LSP and the remote LSP we launch are none the wiser. Because of this proxy, when you go to definition, you are going to load the local source definition; when you go an lsp format tool, it runs remotely and the file sync gets you results locally.
The lsp functionality is pretty barebones but has been working for me in sublime when I open a project of mine in a graft connected directory. I've tested it on golang and typescript. I believe python should work but I suppose dependencies could be funky depending on how you synchronize dependencies (uv, pip, etc.).
For go, I used this on my lsp settings and it worked great. What doesn't work great is if you get disconnected :(. Making the LSP very reliable is another story for another task for another day.
Just so we have a common reference, look at https://github.com/edaniels/graft/blob/main/pkg/local_client.... The main idea is that we are always matching the local current working directory to the corresponding synchronization directory. Using that idea, we serve an LSP locally that rewrites all json-rpc messages that utilize URIs (https://github.com/edaniels/graft/blob/main/pkg/local_client...) from local to remote, and back. The local LSP and the remote LSP we launch are none the wiser. Because of this proxy, when you go to definition, you are going to load the local source definition; when you go an lsp format tool, it runs remotely and the file sync gets you results locally.
The lsp functionality is pretty barebones but has been working for me in sublime when I open a project of mine in a graft connected directory. I've tested it on golang and typescript. I believe python should work but I suppose dependencies could be funky depending on how you synchronize dependencies (uv, pip, etc.).
For go, I used this on my lsp settings and it worked great. What doesn't work great is if you get disconnected :(. Making the LSP very reliable is another story for another task for another day.
{
"log_debug": true,
"clients":
{
"super-gopls":
{
"env": {
"GRAFT_LOG_LEVEL": "debug",
},
"command":
[
"graft",
"lsp",
"gopls"
],
"enabled": false,
"initializationOptions":
{
"analyses":
{
"composites": false,
},
},
"selector": "source.go",
},
},
"lsp_code_actions_on_save":
{
"source.fixAll": true,
"source.organizeImports": true,
},
"lsp_format_on_save": true,
}