duijf

Wow it's great seeing this here again.

The first uni assignment I made for CS101 was a Mandelbrot set renderer. I got it to work, but that's all the merit it had. I didn't have a clue about what I was actually doing.

When I read this post a couple of months later it answered questions I didn't even know I had. Ever since, I try to keep digging if I have that feeling of "There must be more to this.."

Line of business, I think

Working on that API gateway with you was a lot of fun :)

To be fair, we did run into some issues with the GHC garbage collector performance initially. That took some time to figure out and wasn't the easiest thing ever. Like all tools, there are rough edges sometimes.

I still maintain that the Haskell we wrote at the time was pretty cheap in terms of operational load / bugs to fix (especially compared to the systems that they replaced). When I was back at the office for a reunion, I heard that things were still pretty nice in this respect, but maybe someone still at Channable can chime in with more recent stories! (Or complain to me about the code I wrote back then)

Here's a way you can do this with git. This trick relies on `git merge --allow-unrelated-histories`.

Assuming you have repos `foo` and `bar` and want to move them to the new repo `mono`.

    $ ls
    foo
    bar
    
    # Prepare for import: we want to move all files into a new subdir `foo` so
    # we don't get conflicts later. This uses Zsh's extended globs. See
    # https://stackoverflow.com/questions/670460/move-all-files-except-one for
    # bash syntax.
    $ cd foo
    $ setopt extended_glob
    $ mkdir foo
    $ mv ^foo foo
    $ git add .
    $ git commit -m "Prepare foo for import"
    
    # Follow those "move to subdir" steps for `bar` as well.
    
    # Now make the final monorepo
    $ cd ..
    $ mkdir mono
    $ cd mono
    $ git init
    $ touch README.md
    $ git add README.md
    $ git commit -m "Initial commit in mono"
    
    $ git remote add foo ../foo
    $ git fetch foo
    $ git remote add bar ../bar
    $ git fetch bar
    
    # Substitute `main` for `master` or whatever branch you want to import.
    $ git merge --allow-unrelated-histories foo/main
    $ git merge --allow-unrelated-histories bar/main

    # Inspect the final history:
    $ git log --oneline --graph
    *   8aa67e5 (HEAD -> main) Import bar
    |\
    | * eec0abd (bar/main) Prepare bar for import
    | * 9741d6d More stuff in bar
    | * 634ba3d Initial commit bar
    *   43be6e9 Import foo
    |\
    | * d4805a0 (foo/main) Prepare foo for import
    | * 4d2ca10 More stuff in foo
    | * 72072a1 Initial commit foo
    * bfcb339 Initial commit in mono

Form a corporate perspective: 2FA would still force a unique secret per user. That can be useful when your users tend to reuse passwords for different sites or choose poor ones.

I have seen folks use password managers to store their poor non-autogenerated passwords.

For users that do use the PW manager properly, having the PW manager store the TOTP secrets is indeed "putting all of your eggs in one basket".

Thanks for working on this!

I've been using this on and off over the last two months (tend to forget I have it installed and fall back to old habits), but it's really really cool stuff!

More likely May 2021, the date format at the bottom of the post is probably YYYY-MM-DD as common in Germany where the author seems to be located.

EDIT: If Germany has the same conventions as The Netherlands, DD-MM-YYYY is probably even more common

> What is the story in nix for packaging untagged branches of software

Most Nix packages define their sources using `src`. You can pass in whatever you want. E.g. fetch a tarball from GitHub with `fetchUrl`, fetch from a git repository, or point to a local directory.

> or reasoning about "snapshots" where pools of unreleased repos/packages are able to be treated as a single versionable unit?

This is basically what the Nixpkgs collection is minus the "unreleased" part. You can extend Nixpkgs with the packages that you care about using overlays. You have control over the stuff that you put in the overlay, so you can put in unreleased software as well like I described above.

> - I have an existing system for managing packaging metadata which I don't want to migrate from. How much trouble will I get into if I want to generate the metadata on the fly each time (as I currently do for my debs)?

This is difficult to answer without knowing more details.

- You can generate the Nix source files based on the metadata like the sibling comment pointed out.

- Or you could read the metadata with `builtins.fromJSON` and generate Nix derivations programmatically from within Nix.

> - What is the apt/nix interop story?

If you don't want to bother packaging certain applications using Nix (or work towards that gradually), you can. Nothing prevents you from referencing things outside of `/nix/store` in a Nix package. You can launch stuff from `/usr/bin` from a Nix binary if you are so inclined. Libraries are going to be tricky though.

As for the other way around, I'm aware of two options:

- At Channable, we would package the Nix closure of a package in a `.deb`. This works, but you run into trouble when multiple debs need the same store path. You can work around this by packaging the Nix closure under e.g. `/var/lib/<your_package>/nix/store` and bind mounting to `/nix/store` before launching.

- Eventually we realized we didn't want the `/nix/store` stuff in our `.deb` packages. IIRC we created a `postinst` script which ran `nix-env` to realize a store path from our cache + create a GC root so it doesn't get garbage collected.

Some of that stuff may have changed since I left.

Feel free to contact me if you'd like to discuss further. Info is in my profile.