My present setup is using doit to automate setup. I know people use Ansible for similar purposes.
The compelling case to my mind is that actions in Nix are immutable, and that's an amazing story for deploying software to prod, as it makes much stronger guarantees about what you can roll back.
I've actually set up docker images to do things like build old TeX documents simply because it's so bloody difficult to reproduce an earlier state. Nix seems like a much lighter weight answer to that.
 https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-t...  http://pydoit.org/  http://docs.ansible.com/ansible/latest/index.html
I could actually see it being used in conjunction with a script like qpkg, where the script handles compilation and then invokes Exodus to produces self-contained bundles with all of the necessary dependencies. Exodus is generally agnostic to how software it bundles was initially installed or compiled, which has lead to some interesting use cases. For example, we've had a number of people use Docker images to install software from Debian or Alpine package repositories, and then use Exodus to repackage single applications to run in microcontainers.
-  https://github.com/intoli/exodus
-  https://intoli.com/blog/exodus-2/
I think Stow could be easily combined with the ideas in this article to yield something pretty awesome. It already supports clean uninstalls and checking for conflicts, and individual Stow dirs are easily tar-able too. Really, a wrapper around Stow that knows how to handle common configure/make/make install patterns sounds like it'd do the trick.
exodus htop | ssh my-server-name
Something that bugs me about the XDG Base Directory Specification  is that the default is to have a `.config` and `.local` folder in your home directory. I'd rather it all be placed under the single hidden local folder.
On macOS you have ~/Library for user-specific files, /Library for global non-system files, and /System/Library for system files. I think if you use the Network Location feature some apps will also store different preferences in ~/Library/Preferences/ByHost, although I haven't really used the feature so I might be mistaken. Honestly, changing your system preferences based on your location makes tons of sense to me! For a portable system, it doesn't make sense to use the same settings in your home network as when you're in an untrusted network such as a coffee shop or airport.
> export PATH=$HOME/.local/bin:$PATH
> Notice I put it in the front of the list. This is because I want my home directory programs to override system programs with the same name. For what other reason would I install a program with the same name if not to override the system program?
I've always made a point of doing the exact opposite of this when adding to /etc/profile, with the reasoning of: why the hell would I want to allow any user script to be able to override system commands without root permission?
Have I gotten this all wrong? I admit I am no expert on bins and paths and security, but isn't the above a potential security issue?
You're absolutely right, but in the case that a program can write to ~/.local/bin but no where else, it is a concern. What I'm really talking about is when a package manager is using that directory and potentially untrustworthy packages can put whatever they want in ~/.local/bin but not ~
Other users could only override system commands if they can write files to your ~/.local/bin
As /u/CJefferson pointed out, if a user has permission to write files to your ~/.local/bin, they can probably also write to your ~/.profile and ~/.bash_profile.
As long as you control the contents of your home directory, modifying your $PATH to include ~/.local/bin is safe.
For the users's own session, I don't want apt linking to some nefarious bin if for instance I have a npm package whom's authors credentials are hacked at some point, inserting an extra ~/.local/bin/apt binary when it's updated. For this scenario the overriding $PATH method will cause apt to run the nefarious binary rather than the system one.
I think I might have answered my own question through example... it's a security problem when pointing a package manager at the bin where individual package maintainers can publish at any time and be hacked at any time. But I suppose in the authors example, he is using it for his own scripts ONLY, often specifically for the purpose of subverting system package versions, in which case overriding is as safe as the user is.
Active community, with thousands of packages