Presumably this would support a big improvement to both SBOM generation as well as various UX features and workflow improvements.

Trading perfect reproducibility for usability: a pragmatic look at Flox's new features

This is exactly how I can rapidly prototype things. Once proficient with this tooling is becomes very easy to quickly spin up services and PoCs. Managing it and iterating is also a breeze.

Random thought. Another commenter worried about the runtime of the program becoming mangled and performing destructive operations on your machine. What if you run the reducer as a source-to-source Nix derivation? Protects against dangerous things, and can be easily distributed to remote builders.

Oh, that’s a neat idea. To reply to the sibling comment: Nix runs commands under a sandbox. It’s not bullet proof, but useful enough that it will prevent obvious commands like deleting local files and accessing the network.

It took some time to get RustPython to run, but it seems to work fine: https://gist.github.com/judofyr/82d2255c92ebb0c6b3a6882ac9fd...

Also, after running it for 5 minutes it was now able of reducing it to a much smaller case:

    class a:
        def b() : c
        def h(d) :
            while d:
                    break
            else:
                return 
            d.b()
    def j(e) :
        f = a()
        if f.h  () :
                g
    i = ""
    j(i)

You generally shouldn’t use absolute paths in your programs. That makes it dangerous for local development, and makes running two copies of the program to compare behaviors difficult.

There’s a Venn diagram of people who don’t care enough to do that (works for me!) and people who would never think to use c-reduce. It’s not a perfect circle, but it’ll be fairly close.

> You generally shouldn’t use absolute paths in your programs.

This is true, but I was enjoying the irony that there is an old sys-sdmin adage that you should only use absolute paths in your program(usually a shell script, in this environment) this is to make sure it is running exactly what you expect it to run.

So always put "/usr/bin/awk" instead of just "awk"

I had a co-worker once who took this as gospel. His scripts were always... interesting... to port to a new environment.

How does this protect against dangerous things?

My understanding is that this would just cause the dangerous things to be repeatable.

It must be that by running any program within the nix build sandbox you don't expose your files unless you discover a privilege escalation attack by chance during the reduction process.

Agreed. Packaging is different than deployment. Devs should return to the art of packaging, such that their software can be then deployed into containers, VMs, micro VMs, whatever. That is what packaging allows, re-use.

This is the sort of behavior Nix encourages (disclaimer: I work at https://flox.dev , using Nix as our baseline tech). Docker as both a packaging and deployment format can carry a bit of weight, but can quickly get out of hand.

This is excellent. Have you considered making a presentation or a write-up of the experience?

Thanks for the input. A couple of folks suggested that recently as well. Once I can clear up some bandwidth, I do intend to follow through on that. It gave me a huge appreciation for Nix as a build system, and I would love to share that if it were helpful to others.

A similar article for bringing Ruby into the Nix ecosystem: https://flox.dev/blog/flox-and-ruby

This is an excellent pattern. Nix uses it to allow one to create a full transitive build graph, serialized that plan, move it around, and execute it in a distributed and reproducible fashion.

There are always temptations to loosen the constraints this imposes, but they nearly always come at a cost of undermining the value of the pattern.

`flox` needs Nix to function. So the rpm/dev/OSX installers first install Nix, and then installs flox itself.

If you have Nix already, you can try it out as described here: https://flox.dev/docs/install-flox/#install-with-existing-ni....

side-note: with further improvements to Nix as a library, it may be possible to make installing Nix not necessary for flox to function, but this is on a longer time horizon... don't hold your breath

That link in hub.flox.dev is wrong. The link at https://flox.dev/terms-conditions is correct. Fixing.... thanks!