Single binary deployment

Do you prefer to create and deploy software that is a single self-contained binary file? I was looking at the deployment of Python web applications (e.g. Django, Flask), and most of them rely on so many files. Why can't it be in a single self-contained binary named run-app that I can deploy by simply running ./run-app ? What are the programming language implementations that make it easy to produce single-file binary deployments? Of the languages that I have used, I can think of C, C++, OCaml, and probably Java (JAR files).

I believe that nowadays everyone just uses docker images. I think that using Single Binary files sometimes may be "funny" because they may use shared libraries thus breaking at deploy time because whatever server you are using may don't have that libs

>>32483 Check out zipapp , which is a standard (and tool) for packaging python files as a Zip Archive which can be imported and run, or on Linux boxes, marked executable themselves.

Python doesn't do binaries. You can make a binary, but what you're actually doing is bundling all that stuff you don't want into an executable that behaves exactly as if it has that stuff. Almost any compiled language will give you a binary you can just run. Many compilers have the option to create a statically linked binary. Golang does this by default so you can compile something here and it will Just Work over there. Nothing is as nice as Golang in this regard but this use case is catching on in places you wouldn't necessarily expect. See GraalVM.

>>32485 >I think that using Single Binary files sometimes may be "funny" because they may use shared libraries ... Does static linking solve the problem?

>>32489 The "real solution" is much, much crazier, e.g. bundling dynamically linked libraries and then making the storage system deduplicate them despite them being stored in a bundled format (e.g. special tarchive, like how .jar files work), and making the OS optionally or on failure to run or on opt-out basis substitute the bundled dlls to fix bugs in them. And this ignores that you need yet fatter format and execution env (kernel) to support multiple hardware archs.

>>32483 The only sensible way to distribute software is as source code. This naturally creates the issue of using it once it reaches the machine, a problem which was solved and then recreated. Currently, most people are in the sorry situation with software distributed as a compiled representation, and being too complicated to be distributed as source code. Consider a Lisp system, which can load in whatever code and use it in whichever way. It's clear a better system wouldn't allow for this bifurcation. The system should only accept one form of a program, and it should be the form for easy modification. >What are the programming language implementations that make it easy to produce single-file binary deployments? Ada is pleasant to use. A Common Lisp image can be created and then redistributed, but it's not easy. >>32489 Sure, and it only creates several other problems, such as updating the broken software to be less broken later. Amusingly, real operating systems, which no longer exist, had real dynamic linking that didn't break easily.

>>32496 >A Common Lisp image can be created and then redistributed, but it's not easy. >not easy In what world? UIOP even provides an abstraction. The only issue is that the "reference" CL impl is now SBCL and it produces quite fat images, unlike something like ECL.

>>32488 > Golang does this by default so you can compile something here and it will Just Work over there unless you mismatch runtime dependencies like libc case to reproduce: compile on modern ubuntu, run on old centos

>>32497 The issue is that an image only works under the same version of the same implementation, in general. Furthermore, people haven't been trained to ignore the size of a Common Lisp image like they've been trained to ignore the size of Docker nonsense.

>>32483 This is similar, but I prefer it when a piece of software is contained to a single folder. So instead of a .config/program.conf, a .local/share/program/data, et cetera; We just have a single program/ folder with all the config and data stored there. So yes, I prefer a single binary file, although docker makes that way easier to do.

>>32489 static linking means shared libraries are not used. any used libraries are embedded directly in the executable.

>>32499 Oh yeah, wasn't talking about images, but "executables" in SBCL/ECL parlance, that contain the implementation too.

>>32496 >Amusingly, real operating systems, which no longer exist, had real dynamic linking that didn't break easily. What are some examples of "real operating systems"? How did their dynamic linking system differ from what we now have?

>>32496 Currently, most people are in the sorry situation with software distributed as a compiled representation, and being too complicated to be distributed as source code. Consider a Lisp system, which can load in whatever code and use it in whichever way. It's clear a better system wouldn't allow for this bifurcation. This problem still exists. Python is a practical demonstration of exactly what happens in this space. You still have dependencies user may or may not have installed. Users still have various versions of python available. Users still have to install dependencies. Its definitively not as simple as take my .py file and run it. You can argue take my obscure lisp interpreter and install it, but as soon as you do this for any length of time, you will have multiple versions, varying support for platforms, dependencies, foreign function bindings to native libraries, and everything that makes python more difficult than just run the .py >>32485 Pointed out docker images/appImage/Flatpack, which are mostly a solution to the problem by bringing your own userspace. They have the downside of having every project ship all of its dependencies and an entire userspace. There is some duplication with cleaver file system layering in docker, but generally, running every app in a docker image is like kicking dead whales down the beach.

>>32514 >There is some duplication with cleaver file system layering in docker, but generally, running every app in a docker image is like kicking dead whales down the beach. What would be your (or the perfect) solution? not saying this to advocate for docker, im genuinely interested

>>32518 >What would be your (or the perfect) solution? IMO there isn't one. In a perfect world, binary compatability can mostly fuarrrk off, all software is FOSS, CI/CD pipelines build everything rapidly. Developers update their code to use new APIs. Distributions ship fast. I'd like most stuff to be in this bucket. After this has failed, there is static linking, symbol versioning, multiple copies of shared libraries (MSVC 2013, MSVC 2014, MSVC 2015 , ... ), or containerization. Perhaps static linking is the best option - CI/CD can just build with latest version of libs that are supported, and its on whoever to update the source if they care about running with with non-vulnerable library functions.

>>32483 JVM's JAR files, Docker containers or Flatpaks/Appimages? As others have said, Smalltalk images and Common Lisp images work, too. I guess Racket can also make self-contained binaries. >>32520 >binary compatability can mostly fuarrrk off Just distribute your programs as win32 binaries ;). Just test that they work with Wine first, though. https://blog.hiler.eu/win32-the-only-stable-abi/

I see people advocating for the use of Docker to make their programs more self-contained. Isn't Docker rather heavyweight for most software? Look at the size of Docker images. They may take a long time to build because they need to download dependencies from Docker Hub (which introduces supply chain security concerns). There's also the disadvantage that "normal users" do not have Docker preinstalled to run your Docker-packaged programs, so Docker is not suitable for distributing most desktop applications, for example. Docker seems like an over-complication for most software. Other solutions such as static linking are so much simpler by comparison. I may be wrong, but I think Docker has the same disadvantages of statically linked software in that there is duplication of dependencies, and that it requires rebuilding whenever a dependency needs a security update.

>>32520 I wonder if there could be a distribution where the libraries and compilers are only changed (except for security fixes) every couple of years and you could select to install previous versions to run a specific binary. So in essence you ensure backwards compatibility for a couple of versions at the cost of security maintenance.

>>32524 >Docker has duplication of dependencies, >introduces supply chain security concerns) Pretty much accurate. IMO, docker is a lightweight replacement for VM's + infrastructure as code. If you think about docker that way, its an awesome tool. Create a well defined IAC build environment for your software. Create a well defined IAC runtime environment for your software. Ship to production, it works everywhere. If you think of Docker as the right tool to run calc.exe in, its heavyweight, and has all the issues static linking has. Also, Supply Chain issues exist everywhere. If your using github, dockerhub, pypi, or even just distribution repositories, do you really think AUR users are reading the source code they package?

>>32525 I think Debian does that.

>>32532 I don't think Debian can do this easily: >select to install previous versions [of libraries and compilers] to run a specific binary.

>>32525 I believe both Nix and Guix can instantiate arbitrarily old derivations and have them peacefully coexist with newer versions in a running system, at the expense of a non-standard system organization.

>>32486 >Check out zipapp It's not exactly easy to package a Django web application into a zipapp. Few people do it, and you're mostly on your own if you choose do it. This is wholly unlike the Java world, where the popular build tools (e.g. Maven, Gradle) are able to easily package software into JAR or WAR files.