Evaluate use of pkg to make single-binary server #39

Activity

1. kylecarbs commented on Mar 6, 2019

   

   kylecarbs

   on Mar 6, 2019

   Member

   More actions

   We've attempted to use pkg. Using native modules is a large problem we've found, along with differentiating filesystems between inside and outside the binary.

   Using nexe has been alright, but our usage requires a lot of jankiness. Optimally, we'll eventually create our own project to compile the binary.

   We're able to provide the runtime version with nexe.
2. kylecarbs

   added

   discussion

   on Mar 7, 2019
3. sr229 commented on Mar 7, 2019

   

   sr229

   on Mar 7, 2019

   ContributorAuthor

   More actions

   have you tried to open this to Zeit's devs about the problem with native modules @kylecarbs?
4. kylecarbs commented on Mar 7, 2019

   

   kylecarbs

   on Mar 7, 2019

   Member

   More actions

   Seems its an open feature request: vercel/pkg#329
5. nhooyr

   added

   wontfix

   on Mar 8, 2019
6. nhooyr

   closed this as completedon Mar 8, 2019
7. code-asher

   added a commit that references this issue on Jun 19, 2019

   Add ripgrep, fill native fs functions, add ping endpoint (#39)

   ...

   63ef5db
8. aparatext commented on Apr 26, 2022

   

   aparatext

   on Apr 26, 2022

   More actions

   The feature request has been fulfilled. Can anyone investigate if it's possible now?
9. jsjoeio commented on Apr 26, 2022

   

   jsjoeio

   on Apr 26, 2022

   Contributor

   More actions

   I wasn't around when this was being evaluated. @walking-octopus what benefits do you see in us using pkg?
10. aparatext commented on Apr 26, 2022

    

    aparatext

    on Apr 26, 2022

    More actions

    I feel it could be smaller or more convenient than an existing archive. If this was found important enough to hack around the limitations the last time, why not try again?
11. jsjoeio commented on Apr 26, 2022

    

    jsjoeio

    on Apr 26, 2022

    Contributor

    More actions

    Interesting! Smaller is definitely appealing. I don't know the full history around some of the hacks or limitations from the early years of the project.

    @code-asher do you have any context? Is this worth considering?
12. code-asher commented on Apr 27, 2022

    

    code-asher

    on Apr 27, 2022 via email

    Member

    More actions

    To go back a bit first, I think the main draws were that a single binary is easy to run (just download one file and execute it), easy to install (just copy one file), and easy to clean up (just delete one file). Unfortunately the single binary ended up not being straightforward because there are extensions that make file reads to some of the files distributed with code-server which fail because those files are not actually individually on the filesystem; they are in the binary. Another example is the git extension; it was attempting to spawn a shell script distributed with code-server which does not work for the same reason. There may be other broken scenarios we did not discover. To deal with this I believe there were three ideas: 1. Binary extracts parts of itself then we patch reads/spawns/etc to read from the extracted location (we did this for a while). 2. Patch reads/spawns/etc to read directly from the binary (I think we tried this but ran into issues). 3. Binary extracts itself entirely and we run from the extracted location. In practice the first two strategies sort of worked but they were brittle (basically a game of whack-a-mole) and the patching only works for JavaScript code. Self-extraction deviates from why we wanted a single binary in the first place since it is not especially different from an archive except less flexible since you cannot choose the extraction location. If there was a general and robust way of solving these issues then I feel like going back to the single binary would be a good option.

    👍React with 👍1Reacted by Joe Previte