I stole/copied my setup from Nick Janetakis who's just great all around. Its worked for me through several new systems and many updates.
Ask HN: How do you sync your computer’s development configurations/environment?
81–90 of 153 posts
Re: Ask HN: How do you sync your computer’s development configurations/environment?
#82I have a desktop and a laptop, both running the same OS (PopOS).
Note: I don't sync anything to my work computer. I will never trust adding a conduit for my personal activity or files to my work computer.
I use SyncThing which syncs critical parts of my home directory (.config, project files, misc dot files, git configs for multiple profiles). My SyncThing setup is local network only. I work mostly on my desktop and if I'm about to leave I spin my laptop up real quick, it syncs everything in a few seconds, and I'm out the door.
In terms of projects, this also syncs my project settings from VSCode and IntelliJ. I was a little worried about my apps that support hot code reloading if I left the daemon running by mistake, but honestly I've discovered no local state issues.
My shell configuration is also synced, which is really nice. Once homed (in systemd) becomes more of a thing I'll probably see how I can incorporate that workflow.
Re: Ask HN: How do you sync your computer’s development configurations/environment?
#83Not just with development environments, but all computer configuration, I stick with the defaults as much as possible. Instead of changing the configuration of the computer, I change myself. For example, let's say an app has a default keyboard shortcut I don't like. I won't change it. Instead, I'll just get used to it until it becomes muscle memory. Now the default configurations are my preferred configurations. Of c…
Yes, this. Custom configurations are a maintenance burden when you change systems. Living with defaults saves time in the long run, usually. Only when I spot an exception to that rule will I install something custom.
Re: Ask HN: How do you sync your computer’s development configurations/environment?
#84Not just with development environments, but all computer configuration, I stick with the defaults as much as possible. Instead of changing the configuration of the computer, I change myself. For example, let's say an app has a default keyboard shortcut I don't like. I won't change it. Instead, I'll just get used to it until it becomes muscle memory. Now the default configurations are my preferred configurations. Of c…
I think there's a healthy middle ground here. Endless tweaking of settings tends to be a waste of time, but if you spend hours a day on a computer, you might as well make it comfortable. Some people use no $EDITOR plugins and wear it like a badge of honor, this is pretty silly to me. The few minutes it takes to install and learn about a plugin might save you hundreds on hours in the future. I guess my personal strate…
> Some people use no $EDITOR plugins and wear it like a badge of honor, this is pretty silly to me.
I don't use any plugins for PyCharm or IntelliJ, but they're pretty full-featured right out of the box. I certainly don't do it as a badge of honor, that indeed is pretty silly.
But vim is useless without any plugins. Even VSCode is only marginally better than Notepad++ unless you give it the plugins necessary to turn it into an actual IDE and not just a code editor.
Re: Ask HN: How do you sync your computer’s development configurations/environment?
#85I just use nix.
Re: Ask HN: How do you sync your computer’s development configurations/environment?
#86Syncthing is magic. I use it on all my computers (personal/work/home server/etc).
Put the config files in their own directory and then share them with syncthing and then use symlinks to link to them in the right place on each system.
Re: Ask HN: How do you sync your computer’s development configurations/environment?
#87Scripting, scripting, and more scripting. I wish there were a better way, but there isn't. And it will forever be brittle, because operating systems change. With that said, here's what I do.
First, I keep a personal monorepo. It not only has all my dotfiles, but also my personal website, and binary tools I've written. A game changer for me was git submodules, which let me keep third party stuff up to date with a minimum of fuss. The only thing I keep in a separate repo is my password repository.
So the main script I use invokes a lot of other scripts in order. This is so I can just run one thing to update everything. The first thing it does is sync the monorepo and password repos. Then it runs my homebrew stow command, which is like GNU stow[1] but I have all the control I want over it because I wrote it in Ruby. This not only syncs my dotfiles but also copies all my homebrew bins over to where they're not only in $PATH, but /usr/local/bin so that they're in root's path as well.
Next is package management. I run Arch Linux and use pacdef[2] for lightweight declarative package management. If I install some random package, it will remove it at this step, unless I put it in one of my package lists that I keep in the monorepo. This tool will take any Arch Linux install with paru or yay and make it into mostly the system I use every day. It is the most brittle part of the process because, well, operating systems change.
Finally, to manage all the other package management tools out there, I use asdf.[3] My script installs all the plugins if they're not there, update them, then installs everything. Most asdf plugins support a 'default lib' config, which install a list of packages whenever you install a version of the tool. It's not the wholly declarative solution that pacdef is, but I may eventually write enough scripting to get it there.
It has to be this way because Linux is freedom, and with great freedom comes great amounts of time spent learning how it works. I used to try to keep a portable config across OSX, Windows WSL, and Linux, but that was really hard to maintain, and my life got way simpler when I decided no more OSX or Windows. It's kinda possible to do but it's a ton of work.
But the basic building blocks are, 1) dotfiles, 2) system packages, 3) secondary packages. Get those three scripted, and you're off to the races.
[1] https://www.gnu.org/software/stow/
Re: Ask HN: How do you sync your computer’s development configurations/environment?
#88Scripting, scripting, and more scripting. I wish there were a better way, but there isn't. And it will forever be brittle, because operating systems change. With that said, here's what I do. First, I keep a personal monorepo. It not only has all my dotfiles, but also my personal website, and binary tools I've written. A game changer for me was git submodules, which let me keep third party stuff up to date with a mini…
Nix seems like the perfect match for you.
Re: Ask HN: How do you sync your computer’s development configurations/environment?
#89I use Nix to manage: - a desktop running NixOS (primary work machine) - a Macbook (secondary/travel work machine) - a Linux VM on WSL - two servers (a raspberrypi in my closet and a Hetzner vps) I keep my config on Github (latest branch https://github.com/alexghr/nix/tree/host/vader ). I'm still new to this so a lot of my config is duplicated across different hosts but I want to refactor it to eliminate duplication.…
Nix learning curve wouldn't be bad if the documentation wasn't so bad. I have had to put together my configuration based on couple of blogposts from randoms.
Re: Ask HN: How do you sync your computer’s development configurations/environment?
#90Not just with development environments, but all computer configuration, I stick with the defaults as much as possible. Instead of changing the configuration of the computer, I change myself. For example, let's say an app has a default keyboard shortcut I don't like. I won't change it. Instead, I'll just get used to it until it becomes muscle memory. Now the default configurations are my preferred configurations. Of c…
I have a friend who does this. But his reasoning goes one step further. He's usually mentoring people on his team, so he finds it very valuable to be able to not only function quickly on someone else's setup, which is usually the standard, but to give them hints that'll work directly for people unfamiliar with the tools.