Re: A tip, a question, and feature request ...

On 4/10/2013 7:54 AM, Adam Spiers wrote:
 > On Tue, Apr 09, 2013 at 03:45:17PM -0400, Magnus Thor Torfason wrote:
 >> I recently came across stow, and it is a real life-saver. Thank you!
 >
 > Great to hear!  May I ask what your use case is?  These days, most
 > people install system-wide packages using a more conventional modern
 > package manager such as rpm or dpkg, so IMHO the most typically useful
 > use cases which Stow targets has shifted a bit in the last decade.
 > For example I use it for tracking files within my home directory,
 > where use of a conventional package manager is too heavyweight and
 > impractical.

I use stow to manage installs into /usr/local on my Cygwin and OSX 
desktops, and in ~/local on several servers to which I do not have root 
access. Full-fledged package managers are certainly a great boon with 
their integrated dependency checking (I use macports on OSX). But they 
still sometimes have outdated or missing packages, in which case being 
able to compile is crucial. The ability to cleanly uninstall in case a 
package does become available officially is a great boon in this case.

I use svn directly for tracking my configuration files and I'm very 
happy with that setup.

 > It's not for everyone, however; for example, it doesn't work when the
 > target directory is /usr rather than /usr/local, since it would be far
 > too invasive to adopt the whole of /usr.  Similarly for /opt ...

Agreed.

 > The first part of the trick should also please any Stow purists who
 > like the idea of their target directory only containing symlinks owned
 > by Stow.

That would be me

 >>     In this case, one might
 >>     even imagine that the existence of a corresponding file in the
 >>     stow/package directory would be perceived to be a conflict (I
 >>     would expect the actual use case for this switch to always or
 >>     almost always be executed with an empty or (even better) absent
 >>     stow/package directory).
 >
 > Probably better to let the caller decide whether they want to call it
 > with an empty or absent package directory.

Agreed, I'm thinking that when there would be overwriting it would be 
appropriate to give a warning/error. One might for example accidentally 
try to adopt into the wrong version of a recently upgraded package.

Possibly require --force to actually overwrite contents of package 
directory?

 >>   - Update stow and chkstow so that they correctly handle alien 
symlinks.
 >
 > Agreed.
 >
 >>     This would apply to the following commands at least:
 >>       > stow --adopt <package>
 >
 > stow --adopt should currently ignore alien symlinks.  If it doesn't,
 > that's a bug.  I'm not sure what changes you are proposing to this
 > behaviour?

It behaves as you describe. My thought was that if a package installs 
symlinks (like mcview -> mc), they won't be correctly uninstalled on
"stow --adopt-all <package-name> && stow -D <package-name>"
And if there exist identically named files in the package dir, that is a 
conflict I believe (with the current --adopt switch). I admit I'm not 
sure what, if anything, would be a better behavior. (see next para).

 >>       > stow --adopt-all <package>
 >
 > Right, although adopting alien symlinks which are relative rather than
 > absolute could be tricky, since the target of the original alien
 > symlink is relative to its location within the stow target directory,
 > and this target would need to be rewritten during adoption to be
 > relative to its location within the stow package directory.

Yes, it turns out that this would be pretty complex: Absolute links or 
relative links that stay within the same package do work well (I tested 
with the mcview links. But relative links that point neither into the 
package itself nor into the stow dir (so owned by stow) would be very 
problemetic.

Currently my inclination would be to have --adopt-all choke on such 
links unless a --force parameter were passed. But it is far from obvious 
what is the best thing to do in that edge case.

 >>       > chkstow -a
 >>     It seems to me that chkstow -a would have to be aware of the
 >>     location of the stow directory to be able to do this,
 >>     probably by adding a --dir param to chkstow.
 >
 > Agreed, although in the absence of a --dir parameter, the presence of
 > a `.stow' file in the stow directory might be sufficient.

OK, so this would work by traversing all the parents of a symlink's 
targets to see if any of them had a .stow file in it? That seems like a 
bit of overhead. Any ideas for more efficient solutions for that?

And on a related note. Is there a specific reason for separating stow 
and chkstow?

 >>    - Update chkstow -l
 > Yup - my previous comment applies here too.

Cool.

 >>    - It would be very nice if chkstow had the same default
 >>      options for target dir as stow does, and perhaps if
 >>      it could even have a .chkstowrc file?
 >>
 >>    - And even nicer would be if ther was a --rcfile param
 >>      to stow, maybe even for chkstow as well:
 >>        > stow --rcfile=~/my-stowrc-for-homedir <...>
 >>        > stow --rcfile=~/my-stowrc-for-usrlocal <...>
 >>        > chkstow --rcfile=~/my-chkstowrc-for-homedir <...>
 >>        > chkstow --rcfile=~/my-chkstowrc-for-usrlocal <...>
 >
 > This all sounds reasonable.

Cool.

 > Great suggestions; many thanks   Sadly it is very
 > unlikely that I will have time to implement any of these any time
 > soon; however I would be delighted to review and accept pull requests
 > as long as they adhere to these guidelines ...
 >
 > 
http://blog.adamspiers.org/2012/11/10/7-principles-for-contributing-patches-to-software-projects/

Cool. We'll see if anything happens on my front. I've got everything up 
and running now with my aliases and functions, but I'll see whether it 
starts itching again. I've cloned:
https://github.com/aspiers/stow.git
and am running a compiled (and stow-managed) installation of stow, so 
it's straightforward to edit. Would any updates be best submitted as 
pull requests to that repo?

 > Cheers,
 > Adam

Best,
Magnus