10 ms·

GNU Stow needs a co-maintainer

170 points by nequo 3y ago

freedomben 3y ago
I think Savannah is getting an HN hug <3
kstrauser 3y ago
From https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/ : "GNU Stow is a symlink farm manager which takes distinct packages of software and/or data located in separate directories on the filesystem, and makes them appear to be installed in the same place." The idea is that instead of installing package foopkg directly into /usr/local, you could install it to /opt/foopkg-v1.2.3. Then you can run stow to make a bunch of symlinks like /usr/local/bin/foo -> /opt/foopkg-v1.2.3/bin/foo. Upgrade it to a new version, re-run stow, and now all the symlinks point to /opt/foopkg-v4.5.6/bin/foo and so on. It's pretty nifty. However, I used it more for managing dotfiles in my home directory than anything else, making links like ~/.vimrc -> ~/src/my-config-repo/.vimrc . I much prefer using chezmoi for that now.
- Twirrim 3y ago
  >It's pretty nifty. It's how Amazon's stuff used to work (though not using Stow) back several years ago. No idea if they've migrated from that approach to containers, or similar, yet. Every application you deployed would have the necessary components deployed (or re-used if you had something else that already used it), and then build the application space from symlinks to those parts. Worked really well.
  - thrtythreeforty 3y ago
    Ah, symlink farms, how I love to hate thee! They are alive and well.
    - yjftsjthsd-h 3y ago
      Why do you hate them? (FWIW this is a sincere question; given the number of these things I touch, I would very much like to know if there are problems I need to know about and/or better alternatives)
  - tubs 3y ago
    Still works on link farms, yep. And works pretty well!
  - RGamma 3y ago
    Amazon has an internal Nix/Guix? Probably not much public info on this...
    - kstrauser 3y ago
      Alternatively, Amazon is using stow, a common GNU utility whose info page refers to a version of Perl released in 1992, or something similar to it, instead of Nix and Guix which didn't exist when Amazon started.
      - fnordpiglet 3y ago
        Which is also the software this submission is about
      - RGamma 3y ago
        Would Amazon rely on stow when it is in this peril? Unless they really do rely on it and maintain an internal fork, which would make this situation even worse. Or they use it anyway...
      - coldtea 3y ago
        It used neither, but it's own implementation of the concept ("symlink all the things!", which is much older than both, and has lots of other implementations too, aside from Nix and Stow. It's how gobolinux works too, for example.
    - paholg 3y ago
      It's not the same. It's been a while, so I'm sure to get things wrong, but you basically had different package groups you could set up. So a service would have its group that it could update, test, and deploy with at once. But like if I produced a package, and another team depended on it, there was no guarantee that the group I ran in CI had versions in common with the group that they deployed. I also remember some weirdness just within one package, like maybe your PR build was based on your local group setup and not anything "official". The coolest thing about it is that you could make a PR against multiple repos at the same time, even if one depended on the other. Like you could add a function to a library in one repo and call it from another repo in one PR.
- blackeyeblitzar 3y ago
  What is the use case for this? Is the idea that it can automatically turn a package into a portable package, effectively? Or is it so you can install multiple versions of the same software without conflict between them?
  - jonhohle 3y ago
    And so your development environment artifacts can be linked in to the environment root just like any other package (really awesome).
    - blackeyeblitzar 3y ago
      Sorry I’m not super clear on how this works. Could you explain what it means to be linked in to the environment root?
  - kevin_thibedeau 3y ago
    It lets you have informal package management of self-compiled binaries in parallel with your distro's package manager. With Stow you can install updated libs and applications into /usr/local and don't have to be concerned with conflicts. At worst you may need to set LD_PRELOAD to bypass system libs. Very useful with Debian stable when you need a new feature in something and don't want to wrestle with backports.
    - kazinator 3y ago
      I've never had a problem installing self-compiled stuff into /usr/local without conflicts. I'd have to have the problem of installing multiple versions (upgrades) and needing to be able to roll back easily, along with any config files and such.
      - ttyprintk 3y ago
        In the distant past, /usr/local/stow was a NFS mount. Each machine could maintain different symlink trees.
- colonwqbang 3y ago
  I've found that stock git works great for managing dotfiles, without any extra tools needed. Just a few lines of gitconfig and a shell alias is enough. It's all explained here: https://www.atlassian.com/git/tutorials/dotfiles https://www.atlassian.com/git/tutorials/dotfiles Perhaps other people have more complex use cases than me.
  - kstrauser 3y ago
    There's nothing wrong with that setup. It falls over when you start pushing it across multiple machines with substantial differences. Then Chezmoi's templating is so handy. For example, 99% of my config is the same between my desktop Mac and my various Linux servers, but I use different ssh_config settings on the 2 OSes. Chezmoi makes that very easy. Stock git doesn't. I could script something up to do handle that for me automatically, and before I knew about Chezmoi, that's exactly what I did. Now I'd prefer to let someone else write and maintain all that for me so I can move on to working on other things.
    - markstos 3y ago
      I evaluated Stow and tried Chezmoi for a while but settled on YADM. It’s the bare git repo idea with a little more sugar sprinkled on top. Perfect for my needs.
      - dngray 3y ago
        I switched from Yadm to Chezmoi. The main reason was because there invariably is always something slightly sensitive you don't want in a dotfile and the rest of the file is okay. Yadm uses third party tools to do jinja templating. The first one envtpl stopped being maintained, and the second one j2cli (both jinja2 templaters) aren't very well maintained either. With chezmoi I just use the golang text/template templater. I know it will always be maintained. The integrated password manager functionality for chezmoi also works awesome too. I did initially use stow, but symlinks is just bad. You end up with all sorts of problems with that I can't even remember. My whole dotfiles is 7MB, so if a copy is made from a "source tree" to my home dir that's okay. Chezmoi also encouraged me to do things more deterministically based on hosts and reduce the number of "scripts" that I run significantly, which led to less bugs. I use the same set of dotfiles across a number of my systems.
- hawski 3y ago
  Is there an overlap of functionality between GNU Stow and OSTree?
MuffinFlavored 3y ago
[flagged]
- crest 3y ago
  Give him some time to recover first. After all the haters destroyed the fruits of his tireless labour of love to which he dedicated years of his life. /s
- benced 3y ago
  Came here to say exactly this
- deleted 3y ago
  [deleted]
- xyst 3y ago
  Too soon, bro
- shp0ngle 3y ago
  I'll ping Jigar
- rpigab 3y ago
  $ stow --list --whatever-options-i-dont-know-it-just-making-a-joke ssh -> rsh
BeetleB 3y ago
stow was a really useful tool for me once at work. I had a "local" usr/* in my home directory for custom packages I'd install. Occasionally I'd need to swap different versions of the same library, etc. stow made the process a lot more manageable.
- saghm 3y ago
  I've found it useful occasionally for when I've needed to install something via source that didn't include an "uninstall" target in their build configuration. Being able to "unstow" all of the symlinks will clean up all of the system directories, at which point you can just delete the entire folder where the actual installation occurred if you don't want to keep it around at all.
  - BeetleB 3y ago
    Exactly!
- mistrial9 3y ago
  I saw a german after-midnight guy setup postgresql like this once, on linux.. rather quickly ;-) All the significant system parts were in an alternate LD_LIBRARY_PATH plus the postgresl libs
- Karellen 3y ago
  > I had a "local" usr/* in my home directory I always just used `--prefix="$HOME"` so that everything went into `~/bin`, `~/lib`, `~/man`, etc... I did look into stow a couple of times, and would have been fine with it dropping symlinks going into those dirs if I'd have used it. (A few years after XDG started being commonly used I moved everything in my `~/etc` into `~/.config`, and `~/etc` is now a symlink to it. I occasionally wonder if doing it the other way around and setting up XDG_CONFIG_DIR would be more old-skool, before catching my reflection in my monitor and realising how daft that thought is.)
  - BeetleB 3y ago
    > I always just used `--prefix="$HOME"` so that everything went into `~/bin`, `~/lib`, `~/man`, etc... Forgive my ignorance, but how do you uninstall stuff a year or two later?
mike_d 3y ago
Site is getting hugged to death. Maybe we can update the URL? They posted the same notice to GitHub: https://github.com/aspiers/stow/issues/104 https://github.com/aspiers/stow/issues/104
anacrolix 3y ago
It's a trap!
sgammon 3y ago
I love Stow!
- max_k 3y ago
  Me too! I've been using it for 20 or so years, and it's one of those pieces I didn't know it was still developed or what features were added, because the feature set from 20 years ago is still enough for me. IOW: maybe it doesn't need a maintainer at all.
  - LukeShu 3y ago
    I want to share a comment I wrote on the 2.1.0 release announcement in 2011: https://news.ycombinator.com/item?id=3309575 https://news.ycombinator.com/item?id=3309575
jiatan2 3y ago
[flagged]
tfsh 3y ago
I've been using Stow for about two years now to manage my dotfiles. In order to improve the UX I've wrapped it within a small utility which allows me to define packages (directories of dotfiles that should be managed) such as zsh (containing .zshrc, .zshenv, .zlogin, etc) and their respective locations [1]. There's a few other niceties such as modular Zsh file sourcing, allowing encapsulation by OS, automatic git-crypt support, and dependency resolution across mac and debian. I've been tempted to try NixOS due to its emphasis on config-as-code, but this isn't something I can feasibly do as this would fragment my dotfiles across different ways of thinking, which conflicts with my desire to have one repo for every device. Which I've achieved pretty successfully as these dotfiles exist on my personal/work macs, WSL, work/personal linux workstations and a few colleagues devices. All of which works out of the box with a single $ git clone and invocation of a bootstrap.zsh file which installs and sources everything you'd need. The real magic behind all of this is Stow, so I'll always be eternally grateful to its maintainers. If I wasn't a complete stranger to the GNU ecosystem, I'd step up and offer my help. For anyone who's curious here's my dotfiles: https://github.com/o-y/dotfiles https://github.com/o-y/dotfiles 1: https://github.com/o-y/dotfiles/blob/main/bootstrap.zsh#L38-L59 https://github.com/o-y/dotfiles/blob/main/bootstrap.zsh#L38-...
CGamesPlay 3y ago
I evaluated Stow for dotfiles, but I wanted something simpler to deploy (single binary). I built a solution myself several years ago, which shares many features with Stow, and it’s still kicking along. https://github.com/cgamesplay/dfm https://github.com/cgamesplay/dfm
- malobre 3y ago
  Looks great! Seems like GNU Stow inspired many devs, especially around the dotfiles use case
malobre 3y ago
A few years ago I read a blog post [0] on using GNU Stow to manage your dotfiles, I loved the idea and it inspired me to create xdot, a minimalist dotfiles manager [1] which I have been using ever since. [0]: https://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html https://brandon.invergo.net/news/2012-05-26-using-gnu-stow-t... [1]: https://github.com/malobre/xdot https://github.com/malobre/xdot
OJFord 3y ago
I used Stow (some years ago) until I discovered the XDG directory spec. It can be a bit more painful on macOS, but generally enough respects it that it makes more sense to me to use it by default and fix/carve workarounds for what doesn't than to use tools like Stow to essentially put everything in the latter category. That said, I don't imagine it was built for 'dotfiles' as everyone is and will discuss it being used for, so perhaps it does deserve to live on.
throwiforgtnlzy 3y ago
Poor stow. We used it in the stone age about 20 years ago for unpackaged, shared software management on academic research clusters (Think "/usr/{{other hierarchy}}" over NFS). The problem with it is it depends entirely on symlinks and some programs get confused or just don't like them. Nix, hab/habitat, containers, or overlay filesystems (such as with flatpak, etc.) are options that might work better that get around this problem.
- blablabla123 3y ago
  I used to use it quite a lot actually. Nowadays maybe twice a year if I need to install a messy source dependency cleanly. For such rare usages symlink handling is quite a non-issue. When I used it so intensively, actually I mostly used xstow which can automatically resolve common conflicting symlinks on directories, unfortunately that's not maintained anymore. (Sure, there's Nix and containers but stow is way faster)
  - throwiforgtnlzy 3y ago
    Apples (stow) and oranges (containers and exo-package builders and management). When using commands in conflict with the installed base combined and with things that should run unmodified, it gets tricky, usually in the form of shim binaries or improper PATH manipulation, to run things sufficiently isolated and predictably. It's cheap enough and reduces the risks for leaking dependencies to create a chroot/jail/cgroup environment that only includes just enough of a standard environment and its specific dependencies rather than allowing unfettered access to all the things at all times. Depends on what you're doing whether some things can be shoveled in or need more isolation guarantees.
transfire 3y ago
Stow never got enough love. Gobo Linux was based on the same idea, it never got enough love. Now we are paying for it with heavy weight solutions — containers, snaps, flatpak, etc. instead of evolving to a higher-order form of Stow.
- grumbel 3y ago
  Nix and Guix do pretty much that, at the core they are just some symlinks and environment variables. But unlike stow, they build all the rest of the package management and build infrastructure as well. The big issue with stow is that you have to manually get the packages into DESTDIR and quite a lot of packages don't directly support that or do it in their own non-standard way, so there is far too much manual work involved getting anything installed from source. With Nix and Guix you can write a package definition once and than everybody can reuse that instead of reinventing the wheel.
xyst 3y ago
Seems like a zombie project at this point. Maybe a sign that it needs to be put down? - written in perl - 1 maintainer - not much activity on GH or mailing lists - pivot from initial purpose as “symlink farm” to dot file management It’s had a nice run but seems much better alternatives exist now (as mentioned in comments)
- deleted 3y ago
  [deleted]
- mid-kid 3y ago
  It's a simple tool with no dependencies besides perl (which will be around forever) and no cybersecurity footprint. Even if it were to be abandoned for a decade it would still work fine and serve a purpose. There also exists no better alternative for symlink-farm style management. Where do you people keep coming from?
  - fiddlerwoaroof 3y ago
    Perl is not web scale
    - jjgreen 3y ago
      No, it's bigger than that https://xkcd.com/224/ https://xkcd.com/224/
    - mid-kid 3y ago
      What does this even mean??? It's a command-line utility, why does it matter?
      - RGBCube 3y ago
        https://youtu.be/b2F-DItXtZs https://youtu.be/b2F-DItXtZs
    - HeckFeck 3y ago
      Perl is like the language of a sophisticated lost civilisation, its arcane incantations frightening to the current generation. But the achievements of that civilisation are unmistakable.
anticodon 3y ago
I use rcm: https://github.com/thoughtbot/rcm https://github.com/thoughtbot/rcm It is very simple and easy to use, has no external dependencies, and is sufficiently flexible to handle configurations for different machines and other nifty features. I'm aware of Nix and other solutions, but you can start using rcm in 10 minutes (it's really that easy to use). If you choose Nix, for example, you'll need to spend at least several weeks of time (guessing on experience of others).
- pxc 3y ago
  > If you choose Nix, for example, you'll need to spend at least several weeks of time (guessing on experience of others). If you have no prior Nix experience, probably. Home Manager isn't really hard to work with, but its docs do assume basic Nixlang and Nix module system knowledge. If you try to cargo cult your way directly into a working flake with HM, you'll probably get a little lost. But you also don't have to jump in all at once. I used a separate dotfile manager in conjunction with Nix for years, and it worked great. (I only bothered to switch to HM because the tool I was using became unmaintained! I was perfectly happy with it.) You can definitely ease into managing your dotfiles with Nix so it doesn't impose any downtime on you. Using rcm for dotfiles plus Nix for the packages you regularly install is a pretty good idea imo. Then you can transition to using HM for dotfiles management later (or never!).
kazinator 3y ago
I think you can merge multiple directories onto /usr/local using overlayfs. That seems to be what Stow is simulating, using symlinks. Symlinks have the advantage that they persist; you don't have to recreate them after every reboot. Stow also has ignore lists, which isn't something overlayfs will do, or not nicely; it is oriented toward directories. In the package installation use case, you could just keep unwanted cruft out of the individual installation directories that are being combined.
kazinator 3y ago
The GNU Stow documentation has a curious blind spot; it doesn't mention the DESTDIR convention for installing in a separate directory: $ ./configure --prefix=/usr/local $ make $ make install DESTDIR=/usr/local/stow/whatever Using "make prefix=..." is not the main mechanism for overriding the install location; DESTDIR is. DESTDIR is widely supported, and documented in the GNU Coding Standards, in the Makefile Conventions section of the Release Process chapter: https://www.gnu.org/prep/standards/html_node/DESTDIR.html https://www.gnu.org/prep/standards/html_node/DESTDIR.html
- tommiegannert 3y ago
  (Referring to https://www.gnu.org/software/stow/manual/stow.html#Other-FSF-Software https://www.gnu.org/software/stow/manual/stow.html#Other-FSF...) They serve two different purposes. DESTDIR places files in a staging directory, e.g. to be packaged into a tarball. In your example, you will end up with the program at /usr/local/stow/whatever/usr/local/bin, which I'm guessing Stow is trying to avoid, because it's ugly and the extra directories are unnecessary. Not wrong, though. With their approach, it ends up at /usr/local/stow/whatever/bin.
  - deleted 3y ago
    [deleted]
  - kazinator 3y ago
    Right. So if the package supports install time prefix with no hassle, it could be done with make DESTDIR=/usr/local/stow/whatever prefix=/ to get rid of the usr/local components. If the prefix override causes a problem, then just live with the extra components. I'm guessing that in that case you tell stow that your package root is at /usr/local/stow/whatever/usr/local. Stow doesn't care about the extra components; your package can be anywhere you like, right?
    - grumbel 3y ago
      That's not right either. The --prefix needs to be /usr/local or /usr/local/stow/package-1.0, otherwise many packages won't find their own files. The prefix path will get compiled into the binary or configuration for a lot of packages, it's not just an install time thing. Using --prefix=/usr/local/stow/package-1.0 is problematic whenever you have a package with plugins, themes or other stuff, as those go to /usr/local/share/package/... while the app is looking in /usr/local/stow/package-1.0/share/package/ Using DESTDIR and manually removing the usr/local from the directory tree is what I would consider the correct way, even if a bit annoying. Either way, these days I would just recommend to use Nix instead, which is a much more complete solution for what stow tries to do.
mossyfog 3y ago
I use stow as a dotfile manager. works great! only problem is that there are some weird bugs. For example it would get confused when I had a `.fonts/` symlink in my home. Also, the "dot-" prefix really should be a built-in thing and not a fork. But maybe stow wasn't made for this, maybe someone should reinvent stow with dotfiels in mind. And no chezmoi doesn't count.
- TheCleric 3y ago
  I don't use Stow, but in learning what it was I did see that they did a release two days ago that sounds like it may have fixed your issue: https://lists.gnu.org/archive/html/info-stow/2024-04/msg00000.html https://lists.gnu.org/archive/html/info-stow/2024-04/msg0000...
knowsuchagency 3y ago
I heard Jia Tan is available
deleted 3y ago
[deleted]

170 points by nequo 3y ago

I think Savannah is getting an HN hug <3

From https://www.gnu.org/software/stow/ https://www.gnu.org/software/stow/ : "GNU Stow is a symlink farm manager which takes distinct packages of software and/or data located in separate directories on the filesystem, and makes them appear to be installed in the same place." The idea is that instead of installing package foopkg directly into /usr/local, you could install it to /opt/foopkg-v1.2.3. Then you can run stow to make a bunch of symlinks like /usr/local/bin/foo -> /opt/foopkg-v1.2.3/bin/foo. Upgrade it to a new version, re-run stow, and now all the symlinks point to /opt/foopkg-v4.5.6/bin/foo and so on. It's pretty nifty. However, I used it more for managing dotfiles in my home directory than anything else, making links like ~/.vimrc -> ~/src/my-config-repo/.vimrc . I much prefer using chezmoi for that now.

Twirrim 3y ago
>It's pretty nifty. It's how Amazon's stuff used to work (though not using Stow) back several years ago. No idea if they've migrated from that approach to containers, or similar, yet. Every application you deployed would have the necessary components deployed (or re-used if you had something else that already used it), and then build the application space from symlinks to those parts. Worked really well.
- thrtythreeforty 3y ago
  Ah, symlink farms, how I love to hate thee! They are alive and well.
  - yjftsjthsd-h 3y ago
    Why do you hate them? (FWIW this is a sincere question; given the number of these things I touch, I would very much like to know if there are problems I need to know about and/or better alternatives)
- tubs 3y ago
  Still works on link farms, yep. And works pretty well!
- RGamma 3y ago
  Amazon has an internal Nix/Guix? Probably not much public info on this...
  - kstrauser 3y ago
    Alternatively, Amazon is using stow, a common GNU utility whose info page refers to a version of Perl released in 1992, or something similar to it, instead of Nix and Guix which didn't exist when Amazon started.
    - fnordpiglet 3y ago
      Which is also the software this submission is about
    - RGamma 3y ago
      Would Amazon rely on stow when it is in this peril? Unless they really do rely on it and maintain an internal fork, which would make this situation even worse. Or they use it anyway...
    - coldtea 3y ago
      It used neither, but it's own implementation of the concept ("symlink all the things!", which is much older than both, and has lots of other implementations too, aside from Nix and Stow. It's how gobolinux works too, for example.
  - paholg 3y ago
    It's not the same. It's been a while, so I'm sure to get things wrong, but you basically had different package groups you could set up. So a service would have its group that it could update, test, and deploy with at once. But like if I produced a package, and another team depended on it, there was no guarantee that the group I ran in CI had versions in common with the group that they deployed. I also remember some weirdness just within one package, like maybe your PR build was based on your local group setup and not anything "official". The coolest thing about it is that you could make a PR against multiple repos at the same time, even if one depended on the other. Like you could add a function to a library in one repo and call it from another repo in one PR.
blackeyeblitzar 3y ago
What is the use case for this? Is the idea that it can automatically turn a package into a portable package, effectively? Or is it so you can install multiple versions of the same software without conflict between them?
- jonhohle 3y ago
  And so your development environment artifacts can be linked in to the environment root just like any other package (really awesome).
  - blackeyeblitzar 3y ago
    Sorry I’m not super clear on how this works. Could you explain what it means to be linked in to the environment root?
- kevin_thibedeau 3y ago
  It lets you have informal package management of self-compiled binaries in parallel with your distro's package manager. With Stow you can install updated libs and applications into /usr/local and don't have to be concerned with conflicts. At worst you may need to set LD_PRELOAD to bypass system libs. Very useful with Debian stable when you need a new feature in something and don't want to wrestle with backports.
  - kazinator 3y ago
    I've never had a problem installing self-compiled stuff into /usr/local without conflicts. I'd have to have the problem of installing multiple versions (upgrades) and needing to be able to roll back easily, along with any config files and such.
    - ttyprintk 3y ago
      In the distant past, /usr/local/stow was a NFS mount. Each machine could maintain different symlink trees.
colonwqbang 3y ago
I've found that stock git works great for managing dotfiles, without any extra tools needed. Just a few lines of gitconfig and a shell alias is enough. It's all explained here: https://www.atlassian.com/git/tutorials/dotfiles https://www.atlassian.com/git/tutorials/dotfiles Perhaps other people have more complex use cases than me.
- kstrauser 3y ago
  There's nothing wrong with that setup. It falls over when you start pushing it across multiple machines with substantial differences. Then Chezmoi's templating is so handy. For example, 99% of my config is the same between my desktop Mac and my various Linux servers, but I use different ssh_config settings on the 2 OSes. Chezmoi makes that very easy. Stock git doesn't. I could script something up to do handle that for me automatically, and before I knew about Chezmoi, that's exactly what I did. Now I'd prefer to let someone else write and maintain all that for me so I can move on to working on other things.
  - markstos 3y ago
    I evaluated Stow and tried Chezmoi for a while but settled on YADM. It’s the bare git repo idea with a little more sugar sprinkled on top. Perfect for my needs.
    - dngray 3y ago
      I switched from Yadm to Chezmoi. The main reason was because there invariably is always something slightly sensitive you don't want in a dotfile and the rest of the file is okay. Yadm uses third party tools to do jinja templating. The first one envtpl stopped being maintained, and the second one j2cli (both jinja2 templaters) aren't very well maintained either. With chezmoi I just use the golang text/template templater. I know it will always be maintained. The integrated password manager functionality for chezmoi also works awesome too. I did initially use stow, but symlinks is just bad. You end up with all sorts of problems with that I can't even remember. My whole dotfiles is 7MB, so if a copy is made from a "source tree" to my home dir that's okay. Chezmoi also encouraged me to do things more deterministically based on hosts and reduce the number of "scripts" that I run significantly, which led to less bugs. I use the same set of dotfiles across a number of my systems.
hawski 3y ago
Is there an overlap of functionality between GNU Stow and OSTree?

MuffinFlavored 3y ago

[flagged]

crest 3y ago
Give him some time to recover first. After all the haters destroyed the fruits of his tireless labour of love to which he dedicated years of his life. /s
benced 3y ago
Came here to say exactly this
deleted 3y ago
[deleted]
xyst 3y ago
Too soon, bro
shp0ngle 3y ago
I'll ping Jigar
rpigab 3y ago
$ stow --list --whatever-options-i-dont-know-it-just-making-a-joke ssh -> rsh

BeetleB 3y ago

stow was a really useful tool for me once at work. I had a "local" usr/* in my home directory for custom packages I'd install. Occasionally I'd need to swap different versions of the same library, etc. stow made the process a lot more manageable.

saghm 3y ago
I've found it useful occasionally for when I've needed to install something via source that didn't include an "uninstall" target in their build configuration. Being able to "unstow" all of the symlinks will clean up all of the system directories, at which point you can just delete the entire folder where the actual installation occurred if you don't want to keep it around at all.
- BeetleB 3y ago
  Exactly!
mistrial9 3y ago
I saw a german after-midnight guy setup postgresql like this once, on linux.. rather quickly ;-) All the significant system parts were in an alternate LD_LIBRARY_PATH plus the postgresl libs
Karellen 3y ago
> I had a "local" usr/* in my home directory I always just used `--prefix="$HOME"` so that everything went into `~/bin`, `~/lib`, `~/man`, etc... I did look into stow a couple of times, and would have been fine with it dropping symlinks going into those dirs if I'd have used it. (A few years after XDG started being commonly used I moved everything in my `~/etc` into `~/.config`, and `~/etc` is now a symlink to it. I occasionally wonder if doing it the other way around and setting up XDG_CONFIG_DIR would be more old-skool, before catching my reflection in my monitor and realising how daft that thought is.)
- BeetleB 3y ago
  > I always just used `--prefix="$HOME"` so that everything went into `~/bin`, `~/lib`, `~/man`, etc... Forgive my ignorance, but how do you uninstall stuff a year or two later?

mike_d 3y ago

Site is getting hugged to death. Maybe we can update the URL? They posted the same notice to GitHub: https://github.com/aspiers/stow/issues/104 https://github.com/aspiers/stow/issues/104

anacrolix 3y ago

It's a trap!

sgammon 3y ago

I love Stow!

max_k 3y ago
Me too! I've been using it for 20 or so years, and it's one of those pieces I didn't know it was still developed or what features were added, because the feature set from 20 years ago is still enough for me. IOW: maybe it doesn't need a maintainer at all.
- LukeShu 3y ago
  I want to share a comment I wrote on the 2.1.0 release announcement in 2011: https://news.ycombinator.com/item?id=3309575 https://news.ycombinator.com/item?id=3309575

jiatan2 3y ago

[flagged]

tfsh 3y ago

I've been using Stow for about two years now to manage my dotfiles. In order to improve the UX I've wrapped it within a small utility which allows me to define packages (directories of dotfiles that should be managed) such as zsh (containing .zshrc, .zshenv, .zlogin, etc) and their respective locations [1]. There's a few other niceties such as modular Zsh file sourcing, allowing encapsulation by OS, automatic git-crypt support, and dependency resolution across mac and debian. I've been tempted to try NixOS due to its emphasis on config-as-code, but this isn't something I can feasibly do as this would fragment my dotfiles across different ways of thinking, which conflicts with my desire to have one repo for every device. Which I've achieved pretty successfully as these dotfiles exist on my personal/work macs, WSL, work/personal linux workstations and a few colleagues devices. All of which works out of the box with a single $ git clone and invocation of a bootstrap.zsh file which installs and sources everything you'd need. The real magic behind all of this is Stow, so I'll always be eternally grateful to its maintainers. If I wasn't a complete stranger to the GNU ecosystem, I'd step up and offer my help. For anyone who's curious here's my dotfiles: https://github.com/o-y/dotfiles https://github.com/o-y/dotfiles 1: https://github.com/o-y/dotfiles/blob/main/bootstrap.zsh#L38-L59 https://github.com/o-y/dotfiles/blob/main/bootstrap.zsh#L38-...

CGamesPlay 3y ago

I evaluated Stow for dotfiles, but I wanted something simpler to deploy (single binary). I built a solution myself several years ago, which shares many features with Stow, and it’s still kicking along. https://github.com/cgamesplay/dfm https://github.com/cgamesplay/dfm

malobre 3y ago
Looks great! Seems like GNU Stow inspired many devs, especially around the dotfiles use case

malobre 3y ago

A few years ago I read a blog post [0] on using GNU Stow to manage your dotfiles, I loved the idea and it inspired me to create xdot, a minimalist dotfiles manager [1] which I have been using ever since. [0]: https://brandon.invergo.net/news/2012-05-26-using-gnu-stow-to-manage-your-dotfiles.html https://brandon.invergo.net/news/2012-05-26-using-gnu-stow-t... [1]: https://github.com/malobre/xdot https://github.com/malobre/xdot

OJFord 3y ago

I used Stow (some years ago) until I discovered the XDG directory spec. It can be a bit more painful on macOS, but generally enough respects it that it makes more sense to me to use it by default and fix/carve workarounds for what doesn't than to use tools like Stow to essentially put everything in the latter category. That said, I don't imagine it was built for 'dotfiles' as everyone is and will discuss it being used for, so perhaps it does deserve to live on.

throwiforgtnlzy 3y ago

Poor stow. We used it in the stone age about 20 years ago for unpackaged, shared software management on academic research clusters (Think "/usr/{{other hierarchy}}" over NFS). The problem with it is it depends entirely on symlinks and some programs get confused or just don't like them. Nix, hab/habitat, containers, or overlay filesystems (such as with flatpak, etc.) are options that might work better that get around this problem.

blablabla123 3y ago
I used to use it quite a lot actually. Nowadays maybe twice a year if I need to install a messy source dependency cleanly. For such rare usages symlink handling is quite a non-issue. When I used it so intensively, actually I mostly used xstow which can automatically resolve common conflicting symlinks on directories, unfortunately that's not maintained anymore. (Sure, there's Nix and containers but stow is way faster)
- throwiforgtnlzy 3y ago
  Apples (stow) and oranges (containers and exo-package builders and management). When using commands in conflict with the installed base combined and with things that should run unmodified, it gets tricky, usually in the form of shim binaries or improper PATH manipulation, to run things sufficiently isolated and predictably. It's cheap enough and reduces the risks for leaking dependencies to create a chroot/jail/cgroup environment that only includes just enough of a standard environment and its specific dependencies rather than allowing unfettered access to all the things at all times. Depends on what you're doing whether some things can be shoveled in or need more isolation guarantees.

transfire 3y ago

Stow never got enough love. Gobo Linux was based on the same idea, it never got enough love. Now we are paying for it with heavy weight solutions — containers, snaps, flatpak, etc. instead of evolving to a higher-order form of Stow.

grumbel 3y ago
Nix and Guix do pretty much that, at the core they are just some symlinks and environment variables. But unlike stow, they build all the rest of the package management and build infrastructure as well. The big issue with stow is that you have to manually get the packages into DESTDIR and quite a lot of packages don't directly support that or do it in their own non-standard way, so there is far too much manual work involved getting anything installed from source. With Nix and Guix you can write a package definition once and than everybody can reuse that instead of reinventing the wheel.

xyst 3y ago

Seems like a zombie project at this point. Maybe a sign that it needs to be put down? - written in perl - 1 maintainer - not much activity on GH or mailing lists - pivot from initial purpose as “symlink farm” to dot file management It’s had a nice run but seems much better alternatives exist now (as mentioned in comments)

deleted 3y ago
[deleted]
mid-kid 3y ago
It's a simple tool with no dependencies besides perl (which will be around forever) and no cybersecurity footprint. Even if it were to be abandoned for a decade it would still work fine and serve a purpose. There also exists no better alternative for symlink-farm style management. Where do you people keep coming from?
- fiddlerwoaroof 3y ago
  Perl is not web scale
  - jjgreen 3y ago
    No, it's bigger than that https://xkcd.com/224/ https://xkcd.com/224/
  - mid-kid 3y ago
    What does this even mean??? It's a command-line utility, why does it matter?
    - RGBCube 3y ago
      https://youtu.be/b2F-DItXtZs https://youtu.be/b2F-DItXtZs
  - HeckFeck 3y ago
    Perl is like the language of a sophisticated lost civilisation, its arcane incantations frightening to the current generation. But the achievements of that civilisation are unmistakable.

anticodon 3y ago

I use rcm: https://github.com/thoughtbot/rcm https://github.com/thoughtbot/rcm It is very simple and easy to use, has no external dependencies, and is sufficiently flexible to handle configurations for different machines and other nifty features. I'm aware of Nix and other solutions, but you can start using rcm in 10 minutes (it's really that easy to use). If you choose Nix, for example, you'll need to spend at least several weeks of time (guessing on experience of others).

pxc 3y ago
> If you choose Nix, for example, you'll need to spend at least several weeks of time (guessing on experience of others). If you have no prior Nix experience, probably. Home Manager isn't really hard to work with, but its docs do assume basic Nixlang and Nix module system knowledge. If you try to cargo cult your way directly into a working flake with HM, you'll probably get a little lost. But you also don't have to jump in all at once. I used a separate dotfile manager in conjunction with Nix for years, and it worked great. (I only bothered to switch to HM because the tool I was using became unmaintained! I was perfectly happy with it.) You can definitely ease into managing your dotfiles with Nix so it doesn't impose any downtime on you. Using rcm for dotfiles plus Nix for the packages you regularly install is a pretty good idea imo. Then you can transition to using HM for dotfiles management later (or never!).

kazinator 3y ago

I think you can merge multiple directories onto /usr/local using overlayfs. That seems to be what Stow is simulating, using symlinks. Symlinks have the advantage that they persist; you don't have to recreate them after every reboot. Stow also has ignore lists, which isn't something overlayfs will do, or not nicely; it is oriented toward directories. In the package installation use case, you could just keep unwanted cruft out of the individual installation directories that are being combined.

kazinator 3y ago

The GNU Stow documentation has a curious blind spot; it doesn't mention the DESTDIR convention for installing in a separate directory: $ ./configure --prefix=/usr/local $ make $ make install DESTDIR=/usr/local/stow/whatever Using "make prefix=..." is not the main mechanism for overriding the install location; DESTDIR is. DESTDIR is widely supported, and documented in the GNU Coding Standards, in the Makefile Conventions section of the Release Process chapter: https://www.gnu.org/prep/standards/html_node/DESTDIR.html https://www.gnu.org/prep/standards/html_node/DESTDIR.html

tommiegannert 3y ago
(Referring to https://www.gnu.org/software/stow/manual/stow.html#Other-FSF-Software https://www.gnu.org/software/stow/manual/stow.html#Other-FSF...) They serve two different purposes. DESTDIR places files in a staging directory, e.g. to be packaged into a tarball. In your example, you will end up with the program at /usr/local/stow/whatever/usr/local/bin, which I'm guessing Stow is trying to avoid, because it's ugly and the extra directories are unnecessary. Not wrong, though. With their approach, it ends up at /usr/local/stow/whatever/bin.
- deleted 3y ago
  [deleted]
- kazinator 3y ago
  Right. So if the package supports install time prefix with no hassle, it could be done with make DESTDIR=/usr/local/stow/whatever prefix=/ to get rid of the usr/local components. If the prefix override causes a problem, then just live with the extra components. I'm guessing that in that case you tell stow that your package root is at /usr/local/stow/whatever/usr/local. Stow doesn't care about the extra components; your package can be anywhere you like, right?
  - grumbel 3y ago
    That's not right either. The --prefix needs to be /usr/local or /usr/local/stow/package-1.0, otherwise many packages won't find their own files. The prefix path will get compiled into the binary or configuration for a lot of packages, it's not just an install time thing. Using --prefix=/usr/local/stow/package-1.0 is problematic whenever you have a package with plugins, themes or other stuff, as those go to /usr/local/share/package/... while the app is looking in /usr/local/stow/package-1.0/share/package/ Using DESTDIR and manually removing the usr/local from the directory tree is what I would consider the correct way, even if a bit annoying. Either way, these days I would just recommend to use Nix instead, which is a much more complete solution for what stow tries to do.

mossyfog 3y ago

I use stow as a dotfile manager. works great! only problem is that there are some weird bugs. For example it would get confused when I had a `.fonts/` symlink in my home. Also, the "dot-" prefix really should be a built-in thing and not a fork. But maybe stow wasn't made for this, maybe someone should reinvent stow with dotfiels in mind. And no chezmoi doesn't count.

TheCleric 3y ago
I don't use Stow, but in learning what it was I did see that they did a release two days ago that sounds like it may have fixed your issue: https://lists.gnu.org/archive/html/info-stow/2024-04/msg00000.html https://lists.gnu.org/archive/html/info-stow/2024-04/msg0000...

knowsuchagency 3y ago

I heard Jia Tan is available

deleted 3y ago

[deleted]