6 ms·

I like this idea. Can you elaborate a little bit on how/where you would fetch the gem package without the language based package manager, and how this is linked

I like this idea. Can you elaborate a little bit on how/where you would fetch the gem package without the language based package manager, and how this is linked to system deps? For dynamic web application deploys the self-contained binary seems ideal, but I've fallen back on Ansible to properly configure the server dependencies, along with gems that may have system dependencies (e.g. psql).

manveru 9y ago
I've done that for a number of languages (ruby, python, perl, java, haskell, elm, c, erlang, lua, tcl, etc.) and their inevitable "yet another package manager" via nix. Making them all use hashed fixed input sources without allowing any networking or file access during their build and install phases brings me great joy. That's not only useful for deployment but also so you don't end up with development environments that have subtle differences. This enables me to focus more on my developer job. Getting things done faster and with confidence. I'm sure at some point, just like with programming languages, people will start to ask for more immutability and reproducibility in their OS as well.
dozzie 9y ago
> [...] how/where you would fetch the gem package without the language based package manager, and how this is linked to system deps? You unnecessarily constrain yourself too much. You don't need language specific package manager at all for deployment. For building a binary package you probably need it, but not connected to network. And then you need it with network for downloading source tarballs to include in source package (SRPM or similar). Note that the source package is an important step, as you want to host all necessary code yourself, without relying on randomly changing policies of package registries like NPM. The sad part is that language specific package managers cram together downloading, building, and installing, instead of providing them primarly as three separate steps. (You usually can run each separately, but crippled in some whay, e.g. you don't get proper dependency solving for download, or you need to manually order building the dependencies.) > [...] how [binary packages] is linked to system deps? Normally. Your application requires libpq.so? You mention it in Depends: (or allow the build scripts to detect that). You need sloccount? You mention it in Depends:. You need crontab entries? You put them in /etc/cron.d and add cron to Depends:.

manveru 9y ago

I've done that for a number of languages (ruby, python, perl, java, haskell, elm, c, erlang, lua, tcl, etc.) and their inevitable "yet another package manager" via nix. Making them all use hashed fixed input sources without allowing any networking or file access during their build and install phases brings me great joy. That's not only useful for deployment but also so you don't end up with development environments that have subtle differences. This enables me to focus more on my developer job. Getting things done faster and with confidence. I'm sure at some point, just like with programming languages, people will start to ask for more immutability and reproducibility in their OS as well.

dozzie 9y ago

> [...] how/where you would fetch the gem package without the language based package manager, and how this is linked to system deps? You unnecessarily constrain yourself too much. You don't need language specific package manager at all for deployment. For building a binary package you probably need it, but not connected to network. And then you need it with network for downloading source tarballs to include in source package (SRPM or similar). Note that the source package is an important step, as you want to host all necessary code yourself, without relying on randomly changing policies of package registries like NPM. The sad part is that language specific package managers cram together downloading, building, and installing, instead of providing them primarly as three separate steps. (You usually can run each separately, but crippled in some whay, e.g. you don't get proper dependency solving for download, or you need to manually order building the dependencies.) > [...] how [binary packages] is linked to system deps? Normally. Your application requires libpq.so? You mention it in Depends: (or allow the build scripts to detect that). You need sloccount? You mention it in Depends:. You need crontab entries? You put them in /etc/cron.d and add cron to Depends:.