Shop OBEX P1 Docs P2 Docs Learn Events
Bringing Propeller tooling to Nix (Linux/OSX) and NixOS — Parallax Forums

Bringing Propeller tooling to Nix (Linux/OSX) and NixOS

__red____red__ Posts: 470
in Propeller 1
Background:

I do all my development on a linux distribution called NixOS. It's a Linux distro based on the Nix package manager. I'm in the process of packaging all the Propeller tooling for this package manager.

I don't run NixOS, why you should I care?

Nix will run on pretty much any Linux / OSX system. If you've used 'brew' on OSX, it's like that but has a better model imho. As I add the packages to NixOS, they will automatically be tested, compiled, and published for other OSs / platforms / architectures.

Once I have the packages made, you'll be able to just install them on any of those above platforms.

So you're not done, why are you telling me this?

This is more a heads-up for the maintainers more than a notice to end-users. As I go through each of the tools in turn I may start raising PRs to make the build process slightly more generic so it can target more systems.

I could just package up for the one OS. I could just do hackery in the Nix buildsystem. It just seems to me to make more sense to push improvements upstream for evaluation.


__red__

Comments

  • DavidZemonDavidZemon Posts: 2,973
    Heh... nix. Fun. We recently had a discussion at our office about what package manager to use, and the difference between a build-time package manager and runtime package manager (i.e.: maven/gradle/conan/npm/pip vs apt/rpm/brew). Nix was by far the WEIRDEST of any of these. We only put a single sentence for our description of it:
    Use all the symlinks. There are over 9000 symlinks.

    Good luck and have fun :)
  • __red____red__ Posts: 470
    It certainly is a mental adjustment - but that model does result in every single executable being able to specify its own dependency tree completely insulated from everything else on your machine.

    It is impossible to get into "dependancy-hell"[tm] in a Nix system.

    ... and NixOS? All upgrades / re-configurations are atomic and can be cleanly reverted.

    You should look again :-) <3
  • __red____red__ Posts: 470
    btw, I see you maintain a CI for these tools.

    I'm hoping to push a PR to OpenSpin - any chance you could run your CI against my master to validate that it's not going to break your CI if accepted?

    URL: https://github.com/redvers/OpenSpin

    Thanks
  • DavidZemonDavidZemon Posts: 2,973
    __red__ wrote: »
    It certainly is a mental adjustment - but that model does result in every single executable being able to specify its own dependency tree completely insulated from everything else on your machine.

    It is impossible to get into "dependancy-hell"[tm] in a Nix system.

    ... and NixOS? All upgrades / re-configurations are atomic and can be cleanly reverted.

    You should look again :-) <3

    Thankfully, I convinced the guy making the decision that we should stick with deb instead since customers are more likely to be familiar with it. And we're using Conan for compile-time package management (it's working out reasonably well, as C/C++ package managers go anyway).
    __red__ wrote: »
    btw, I see you maintain a CI for these tools.

    I'm hoping to push a PR to OpenSpin - any chance you could run your CI against my master to validate that it's not going to break your CI if accepted?

    URL: https://github.com/redvers/OpenSpin

    Thanks

    Done! All built successfully. http://david.zemon.name:8111/project.html?projectId=OpenSpin&branch_OpenSpin=__all_branches__ Shoot me a PM whenever you're ready for them to be removed. If you think your fork will be long-standing, I'll move these builds to their own project, but this was at least easy to start with.
  • __red____red__ Posts: 470
    PR just got committed.

    Works on yours.
    Works in Nix.

    Win!

    Thanks again!
  • DavidZemonDavidZemon Posts: 2,973
    Cool! Congrats :D
  • __red____red__ Posts: 470
    DavidZemon wrote: »
    Cool! Congrats :D

    Thanks.

    Quick question - is it possible to see the build instructions for your CI server? ie, here's where the sources are downloaded from, here's how each artifact is built... etc ?

  • DavidZemonDavidZemon Posts: 2,973
    __red__ wrote: »
    DavidZemon wrote: »
    Cool! Congrats :D

    Thanks.

    Quick question - is it possible to see the build instructions for your CI server? ie, here's where the sources are downloaded from, here's how each artifact is built... etc ?

    Certainly. Let's pick this up via PM or email or a phone call. The next step is to create you a user account.
  • pedwardpedward Posts: 1,642
    __red__ wrote: »
    It is impossible to get into "dependancy-hell"[tm] in a Nix system.

    Not to create a war, but UNIX has had this figured out for ages, I only know of Windows having this problem.

    $ldd /bin/bash
    linux-vdso.so.1 (0x00007fff709c8000)
    libtinfo.so.6 => /lib64/libtinfo.so.6 (0x00007f10d1c2a000)
    libdl.so.2 => /lib64/libdl.so.2 (0x00007f10d1a26000)
    libc.so.6 => /lib64/libc.so.6 (0x00007f10d1667000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f10d2174000)

    The problem is solved because whether you need so.1, so.2, or so.6, the dependencies are baked in at compile time, and the package managers solve the "what package provides what dependency" problem.

    I see some value in things like AppImage, especially for programs like kdenlive, which is a hot mess when it comes to libraries that it will run with reliably, so AppImage solves that particular issue. I blame kdenlive more than anything, for being so unstable.

    AppImage also solves the distro war problem, since it's distro agnostic and would allow any Propeller tools to "just work" on pretty much any architecture-compatible system (i86, x86_64).
  • __red____red__ Posts: 470
    No war declared :smiley:
    The problem is solved because whether you need so.1, so.2, or so.6, the dependencies are baked in at compile time,
    and the package managers solve the "what package provides what dependency" problem.

    Except they very frequently don't. Maybe you've been lucky?... Even the wikipedia entry for the term focuses on rpm.

    Things are getting better with more developers taking up semantic versioning... but all the while package integrators pin to specific minor revs you're going to have this problem.

    In your example, not all libc.6 are made the same...
  • Wuerfel_21Wuerfel_21 Posts: 5,053
    I heard flatpacks are pretty cool: Applications bundle all their required libraries, apart from some common ones, but duplicate files are automagically deduplicated.
  • __red____red__ Posts: 470
    Yup - and there's certainly a lot to be said for just static-linking if you're only going to run one instance of your application on a system too.

    With nix as a package manager it basically creates its own independent 'flatpack'[tm]
Sign In or Register to comment.