This is what AppImage gets that the rest of Linux doesn't seem to: if an application is a single file/folder, you don't need anything more complicated than a file manager to manage it.
P.S.: after a quick glance at some documentation, I don't see any mechanism that would allow me to install nix packages to arbitrary locations anyway.
Nevertheless it can be done - if you are dedicated, recompile the program with the prefix changed to the mounted root of your separate drive. Presto, automated installs to your external drive. Now, linking up all the bits can still be a right headache, but this is just a bigger nightmare on Windows (what will you DO if your drive letter changes?? You mean I don't have any system to automatically link up random programs on random drives which may or may not be present. Gosh darn, that package manager sounds like a good idea now...)
If you're using a laptop, you're probably due for an upgrade in HDD capacity, or if you're lucky enough to be on Desktop I'd recommend a board with hotplug capability and using LVM. I think no matter your platform you're going to have a hell of a lot of problems doing things your way. If you can patch the package manager to be able to do this, amazing! I don't think any system exists like this, period.
I had similar problem. I joined two physical disks into one logical using LVM and forgot about problem. :-/
Well that's still better, in my opinion, than package managers and all their various restrictions. But ideally I want something like AppImage, where an application is a singular entity that can just be moved at will and run from wherever [0]. Most DOS programs and many Windows programs (if you extract them from the installer) will still work like that.
> I had similar problem. I joined two physical disks into one logical using LVM and forgot about problem. :-/
If you unplug the external disk, your system stops working. This is not what I want, as I mentioned already in the post you're replying to.
[0] classic MacOS, RiscOS, and NeXT all had programs that worked like this too. Linux has yet to achieve the flexibility in application management afforded by the OSs of the 1980s.
Kinda illustrates my point about this being a foreign concept to Linux Desktop people. It's pretty simple: I want to put an application on an external disk and run it from there.
> if you have a separate OS on the external drive, you could chroot in and install it.
No thanks. I'd just like to have the application stored on an external disk, and execute it on the OS I have installed.
> If you just want that one application to be on the other disk, you could mount it to wherever on the filesystem the program would be installed.
Not really, because Linux likes to have an application spread its files all over the hierarchy, so in reality I need to either use some form of union-mounting, and/or simlinks. Of course that is only sufficient if there are no library conflicts between what the application wants and what the system uses, in that case I need to use LD_LIBRARY_PATH and other tricks. In some cases I'll need to use a launch script that calls a different ld.so.
That's a lot of hoops compared to how sane operating systems do it.
> LVM to share disk space between the disks
System breaks when disk is removed. No good.
> Flatpak, Snap, Appimage and other portable format aren't really preferable. they lead to a software ecosystem that amounts to just downloading and running executable binaries off the internet, each with their own overhead.
Which is pretty much what I want, because the alternative is dealing with the bullshit I mentioned above whenever you step outside the package manager's sandbox.