3 ms·
I disagree. Defining packages is pretty easy, e.g. with import <nixpkgs> {}; runCommand "my-thing" { someSortOfSource = fetchurl {
by chriswarbo 5y ago
I disagree. Defining packages is pretty easy, e.g.
with import <nixpkgs> {};
runCommand "my-thing"
{
someSortOfSource = fetchurl {
url = "https://example.com/thing.tar.gz";
sha256 = "0000000000000000000000000000000000000000000000000000000000000000";
};
buildInputs = [ gcc python3 whatever-else-you-like ];
}
''
tar xzf "$someSortOfSource"
cd whateverWasInThatTarball
run whatever commands you like
mv whatever-the-result-should-be "$out"
''
The actual commands can usually be copy/pasted from the README or INSTALL file of whatever project you're "packaging".
> Docker has almost no learning curve, including creating your own images and sharing them with the world.
It took me several attempts to learn Docker, and I'm still very much a newbie with it. To be fair, most of the difficulty I had was due to my misunderstandings; e.g. "surely nobody actually does that?" (e.g. "download entire OS just to run a command"; "ignore all the hashing and just fetch 'latest'"; "run 'apt-get -y update' without having any idea what it's going to do a week from now"; etc.)
Once Docker 'clicked' for me (i.e. I realised that indeed, people are doing that sort of stuff), it became much easier. It's also when I completely lost interest in Docker, and started using OCI containers instead (you can get remarkably far with just 'tar', 'sha256sum' and 'jq'!).
These days my only interaction with Docker is when other people's containers cause an outage at work, due to Docker blowing through all the disk space on our cloud servers. (Fun fact: you can resize AWS disk partitions on-the-fly, but not if they're 100% full, since the partition-editing commands try to allocate temp files)