Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Warp – self-contained, single binary applications

github.com

Post reply on HN
Print view View original

61–70 of 157 posts

Re: Warp – self-contained, single binary applications

#61

Post by dharmab »

weberc2 wrote: post #43
dharmab wrote: post #35

Earlier quoted context omitted.

For Python, this works well for my team: https://www.dharmab.com/programming/python/docker/2017/07/24...

Sorry if I'm a little dense; that doesn't seem like it solves any problems. It just says "use virtualenv and/or docker". I guess I was hoping for "how to manage dependencies in a localdev-friendly way for a Python/Docker app" or something.

Plop a requirements.txt file down in each repo. Use direnv or a similar tool to automatically manage virtualenvs on the local dev machines. In your container, don't use virtualenv; just add requirements.txt to the container and run pip install -r requirements.txt

See the linked code at the bottom of the page

Re: Warp – self-contained, single binary applications

#62

Post by tomc1985 »

mychael wrote: post #46

What problem does this solve? How does it differ from Docker?

This solves some of the app packaging pain that goes into building desktop apps. Not sure how this works but it probably bundles dependencies into the binary a la static linking. Docker mocks the OS and virtualizes, its a very different approach

I'm stoked for anything that eases the pain of desktop deployment that isn't Electron. Right now the cross-platform story is... complicated

Re: Warp – self-contained, single binary applications

#64

Post by ASalazarMX »

w8rbt wrote: post #4

Very neat. Would like to see more languages targeting single binaries. This is one reason (I believe) that has made Go so popular.

I'm ambivalent about this. It is cool to distribute a single binary, but years ago there was serious vulnerability in a very common open source library library whose name escapes me (it wasn't libgcc, someone help a brother here).

It was used in multiple programs in both Windows and Linux. On Windows there was a rush of individual updates as each application was fixed... on Linux, simply upgrading that library fixed all applications.

I'd rather be in the latter than the former situation when the next vulnerability happens.

Re: Warp – self-contained, single binary applications

#65

Post by dev_dull »

rkeene2 wrote: post #29
w8rbt wrote: post #4

Very neat. Would like to see more languages targeting single binaries. This is one reason (I believe) that has made Go so popular.

Tcl is still the king of this kind of distribution with Starkits/Starpacks. Since you can virtualize the filesystem within Tcl, you can pack in all your resources as regular files and generally scripts will work without knowing that this has happened (and without hacky extracting of the archive to disk before running, or while running).

This is an awesome design concept and I'm surprised other languages aren't copying it.

Re: Warp – self-contained, single binary applications

#66

Post by dev_dull »

dharmab wrote: post #61
weberc2 wrote: post #43

Earlier quoted context omitted.

Sorry if I'm a little dense; that doesn't seem like it solves any problems. It just says "use virtualenv and/or docker". I guess I was hoping for "how to manage dependencies in a localdev-friendly way for a Python/Docker app" or something.

Plop a requirements.txt file down in each repo. Use direnv or a similar tool to automatically manage virtualenvs on the local dev machines. In your container, don't use virtualenv; just add requirements.txt to the container and run pip install -r requirements.txt See the linked code at the bottom of the page

There are so many places where this will never work. For example, if you're using openssl and you're system is missing the header files.

Re: Warp – self-contained, single binary applications

#67

Post by tgtweak »

mychael wrote: post #46

What problem does this solve? How does it differ from Docker?

For starters you don't need docker installed, or any container at all. This is largely targeted to end-user deployments where you're providing a binary to users to run, and the current defacto is to make a self extracting exe which dumps all the dependencies along with your executable to a temp directory before executing. Rather messy.

Edit: just looked at the warp implementation, it's a self extractor and executor

Re: Warp – self-contained, single binary applications

#68

Post by solarkraft »

tomc1985 wrote: post #62
mychael wrote: post #46

What problem does this solve? How does it differ from Docker?

This solves some of the app packaging pain that goes into building desktop apps. Not sure how this works but it probably bundles dependencies into the binary a la static linking. Docker mocks the OS and virtualizes, its a very different approach I'm stoked for anything that eases the pain of desktop deployment that isn't Electron. Right now the cross-platform story is... complicated

But it seems like it continues one of the pain point of Electron: Shipping hundreds of MBs in the same dependencies for every single app.

Re: Warp – self-contained, single binary applications

#69

Post by solarkraft »

Koshkin wrote: post #20
weberc2 wrote: post #15

Earlier quoted context omitted.

> The programming field often feels like it's in a giant loop constantly re-discovering what went before. It might feel that way, but this is driven by economics. Basically disk, memory, and bandwidth is far cheaper than it used to be so who cares if you waste a GB or so copying the same libraries all over if you don't have to solve for dependency hell?

> disk is far cheaper Not in the cloud.

1) It is

2) Application space on the server is vanishingly tiny compared to the data you're processing, so it is a far more generous trade-off.

Re: Warp – self-contained, single binary applications

#70

Post by dharmab »

dev_dull wrote: post #66
dharmab wrote: post #61

Earlier quoted context omitted.

Plop a requirements.txt file down in each repo. Use direnv or a similar tool to automatically manage virtualenvs on the local dev machines. In your container, don't use virtualenv; just add requirements.txt to the container and run pip install -r requirements.txt See the linked code at the bottom of the page

There are so many places where this will never work. For example, if you're using openssl and you're system is missing the header files.

Which is why I run and debug locally with an interactive container; installing the packages locally is just for my editor autocompletion.
Post reply on HN