I'm starting to look into that as it seems less awful[0] than package managers in general.
My present setup is using doit[1] to automate setup. I know people use Ansible[2] 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.
While we're on the topic of homebrew package managers, I think some people here might be interested in checking out Exodus [1] [2]. A lot of the project philosophy actually overlaps quite a bit with that of qpkg. Both projects seem to be focused on simplicity, produce tarballs which can be extracted anywhere and run on any Linux machine, and avoid collisions without a centralized database. Unlike qpkg, however, Exodus isn't concerned with compilation and does automatically handle dependencies. It does so by using the system linker to discover required libraries, and then creating small wrapper executables which invoke the linker with the necessary library paths.
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.
I've been using GNU Stow as a pseudo "package manager." Let's me install multiple versions of a software. And I simply delete the directory when I don't need it anymore.
I'll second GNU Stow — I've been using it off-and-on for almost twenty years now (hard to believe that it's been that long!). It does have issues when pre/post-install scripts are required, but that could be easily wrapped.
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.
I wrote something like that more than once. My use case: I am given the account on the machine on which I do not have admin access, but I still want my tools that are not installed: tmux, git, htop, latest version of vim sometimes, dos2unix, ack, etc. So I create ~/usr, and start the process of downloading and compiling tar.gz, with all the proper flags, most importantly --prefix. I automated this with bash scripts to the varying degrees of automation, but has always been wondering if there is a better and established tool for this.
I also keep user-specific binaries in ~/.local/bin. IMO, keeping things clearly separated between the user and system is just the most sensible approach. It also keeps the home directory fairly free of clutter.
Something that bugs me about the XDG Base Directory Specification [0] 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.
Out of interest I followed the link to "installed in my home directory under ~/.local/bin", because I use the same method for "global" user installation of some npm packages and arbitrary little tools I put together... anyway I discovered this:
> 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?
This is often called being "on the wrong side of the airtight hatch". If a program can write to ~/.local/bin, it can write to ~/.profile and change your path anyway, or set aliases.
> allow any user script to be able to override system commands
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.
Well, if you're running as `root`, then `$HOME` will point to `/root`. Assuming `/root` is set to only allow `root:root` to write to it, then you don't need to worry about other users placing binaries at `/root/.local/bin`.
[+] [-] RubenSandwich|8 years ago|reply
[0] https://nixos.org [1] https://nixos.org/nix/
[+] [-] ben509|8 years ago|reply
My present setup is using doit[1] to automate setup. I know people use Ansible[2] 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.
[0] https://nixos.org/nixos/nix-pills/why-you-should-give-it-a-t... [1] http://pydoit.org/ [2] http://docs.ansible.com/ansible/latest/index.html
[+] [-] gkya|8 years ago|reply
[+] [-] foob|8 years ago|reply
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.
- [1] https://github.com/intoli/exodus
- [2] https://intoli.com/blog/exodus-2/
[+] [-] satbyy|8 years ago|reply
[+] [-] zeveb|8 years ago|reply
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.
[+] [-] mynegation|8 years ago|reply
[+] [-] celerity|8 years ago|reply
[+] [-] TheAceOfHearts|8 years ago|reply
Something that bugs me about the XDG Base Directory Specification [0] 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.
[0] https://standards.freedesktop.org/basedir-spec/basedir-spec-...
[+] [-] tomxor|8 years ago|reply
> 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?
[+] [-] CJefferson|8 years ago|reply
[+] [-] avhon1|8 years ago|reply
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.
[+] [-] johnmaguire2013|8 years ago|reply
[+] [-] baber|8 years ago|reply
Active community, with thousands of packages
[+] [-] _ZeD_|8 years ago|reply
[+] [-] pjmlp|8 years ago|reply
[+] [-] VyseofArcadia|8 years ago|reply
[+] [-] Grauwolf|8 years ago|reply
[1] https://gist.github.com/ruario/11246070
[+] [-] jarvuschris|8 years ago|reply
https://bldr.habitat.sh/
[+] [-] agumonkey|8 years ago|reply
[+] [-] avhon1|8 years ago|reply