Re: various suggestions for mr
On Sun, Oct 30, 2011 at 1:26 PM, Adam Spiers wrote: > On Sat, Oct 29, 2011 at 5:52 PM, Joey Hess wrote: >> Adam Spiers wrote: >>> However, the basename operation does not preserve the uniqueness >>> property which $MR_REPO had, and that's why I say that we need an >>> additional namespace. >> >> So pick an operation that does? tr / _ would do, for example. > > The other implicit requirement of this namespace was that it is > easy to remember and type. The rest of my previous email > gives the context for this requirement. OK, I've made a patch which fulfills this requirement pretty well. Hopefully you'll find it reasonably clean and unintrusive: https://github.com/aspiers/kitenet-mr/commit/b9a4e45aefe87c11ade1e4c4022e511f0d96d53c With this patch, if you have .mrconfig files defining repositories: [path/to/foo] ... [path/to/bar] ... then you can limit mr to only act on those via: mr -r foo,bar $action If there is a clash of directory names, then it can be resolved via a new special parameter 'name': [path/to/foo] checkout = git clone ... name = foo.git [path/to/a/different/foo] checkout = cvs checkout ... name = foo.cvs and then you can do: mr -r foo.cvs update etc. ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Sat, Oct 29, 2011 at 5:52 PM, Joey Hess wrote: > Adam Spiers wrote: >> However, the basename operation does not preserve the uniqueness >> property which $MR_REPO had, and that's why I say that we need an >> additional namespace. > > So pick an operation that does? tr / _ would do, for example. The other implicit requirement of this namespace was that it is easy to remember and type. The rest of my previous email gives the context for this requirement. ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
Adam Spiers wrote:
> I already did this; in fact I *had* to, in order to support GNU stow,
> which requires the stow package namespace to be the list of
> directories under a single "stow directory". If you look for
> $STOW_PKG_PATH in the code I originally posted, you'll see:
>
> STOW_DIR=$HOME/.cfg
> ...
> MR_NAME="`basename $MR_REPO`"
> ...
> STOW_PKG_PATH="$STOW_DIR/$MR_NAME"
>
> and then post_{checkout,update} call the install() function which
> does:
>
> ensure_symlink_exists "$STOW_PKG_PATH" "${MR_REPO%/}"
>
> However, the basename operation does not preserve the uniqueness
> property which $MR_REPO had, and that's why I say that we need an
> additional namespace.
So pick an operation that does? tr / _ would do, for example.
--
see shy jo
signature.asc
Description: Digital signature
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Fri, Oct 28, 2011 at 6:08 PM, Joey Hess wrote:
> Having two namespaces for the same thing does not strike me as
> necessarily a good idea.
>
> But if you wanted to do that with mr, you could
> maybe take advantage of a little-known thing it does with determining the
> absolute path:
>
> joey@gnu:~>mkdir namespace
> joey@gnu:~>cd namespace
> joey@gnu:~/namespace>ln -s ~/lib/sound
> joey@gnu:~/namespace>ln -s ~/src/git-annex
> joey@gnu:~/namespace>cd git-annex
> joey@gnu:~/namespace/git-annex>mr update
> mr update: /home/joey/src/git-annex
I already did this; in fact I *had* to, in order to support GNU stow,
which requires the stow package namespace to be the list of
directories under a single "stow directory". If you look for
$STOW_PKG_PATH in the code I originally posted, you'll see:
STOW_DIR=$HOME/.cfg
...
MR_NAME="`basename $MR_REPO`"
...
STOW_PKG_PATH="$STOW_DIR/$MR_NAME"
and then post_{checkout,update} call the install() function which
does:
ensure_symlink_exists "$STOW_PKG_PATH" "${MR_REPO%/}"
However, the basename operation does not preserve the uniqueness
property which $MR_REPO had, and that's why I say that we need an
additional namespace. I can easily hack one, e.g.:
[$HOME/.my-repos/foo]
lib = MR_NAME=my-foo
[$HOME/.upstream-repos/foo]
lib = MR_NAME=your-foo
but that's ugly, and requires execution of shell code which would make
it difficult to implement a reverse lookup from package name to repo
path.
> The only problem with this approach is that it only work when inside the
> symlinked directory, so mr update in ~/namespace won't update the
> directories symlinked to there.
Right. I feel like there's probably some elegant tweak we could make
to mr which would solve all this cleanly without much effort, but I'm
still trying to figure out what it is :-)
Let's examine the status quo. Currently mr has:
- a namespace for repositories (let's call it "R") which is a subset
of the filesystem namespace, and values are specified in mr config
section headers,
- a namespace for mr config files (let's call it "C") which is a
different subset of the filesystem namespace from R, and
- a 1:many mapping between C and R, i.e. each config file can
contain one or more repos.
I don't think there's anything wrong with this design - in fact that
1:many mapping is a nice configuration-time grouping mechanism, but
it's not quite enough to cater for some use cases.
For instance, sometimes it's just not acceptable to update all repos
at once, e.g. if you know that something is broken in repo X but you
really need the updates from repos Y and Z.
However mr cannot currently perform actions on repos at a finer
granularity than how they are grouped in config files. So if you
wanted to update your 'zsh' and 'emacs' repos, you could only do that
if they were in a config file containing no other repos. In general,
unless you restrict yourself to one config file per repo, there is no
way to get mr to operate on an arbitrary subset of R.
Similarly, if the 1:many mapping between C and R is used to logically
group repositories together (e.g. "CLI", "X11" and so on), there is no
way to get mr to operate on an arbitrary collection of groups.
Another issue is that whilst "mr -c $config ls" extracts mappings from
C to R, there's no way to extract the reverse mapping from R to C,
i.e. "what config file do I need to use in order to perform actions
on repo X?"
In summary, maybe the tweak I'm looking for is simply to decouple
configuration-time grouping of repos from run-time selection of which
repos to act on:
[$HOME/.my-repos/emacs]
name = emacs
[$HOME/.my-repos/zsh]
name = my-zsh
[$HOME/.upstream-repos/zsh]
name = upstream-zsh
which would allow:
$ mr -r my-zsh,emacs
And then the reverse mapping from R to C could be extracted via:
[DEFAULT]
showconfig = echo "$MR_CONFIG"
(except at the moment, MR_CONFIG isn't changed via includes
which could cause a problem.)
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: to symlink or not to symlink (was: Re: various suggestions for mr)
On Fri, Oct 28, 2011 at 18:23, Adam Spiers wrote: > Ah thanks, I did wonder about that. Yah, I hope the "old" version will drop off of google at some point to avoid confusion. > Sure, there's no right and wrong. It sounds like your preference is > based on a sense of aesthetics rather than more concrete technical > arguments? Not that there's anything wrong with that - aesthetics are > important too. But if you are aware of some specific technical > advantages of avoiding symlinks, I'd be very interested to hear them > so that I can weigh them up against the alternative. Well, symlinks (on files!) work pretty much exactly as files in the relevant use cases so there's no real downside. > Sure, although that's assuming you have a shell to hand. Almost > always the case, but sometimes it's handy to be able to see with > nothing more than a file manager (e.g. sftp). Definitely not a use case for me. If you really do access $HOME via ftp, that might be useful, though. Though, arguably, if you are not in an interactive shell, what do you care about where what info lives? > More significantly, it doesn't tell you which files are *not* managed > by it. Without symlinks, you have to iterate over all your > repositories, and then filter out those files from the set of files > you are interested in looking at. Valid point, that. Though my fix to the ~/.gitignore issue will address that. > Well, I'm obviously more prone to mistakes than you ;-) But that > aside, I want this setup to support checkout of a large number of > third party software packages which I'm either trying out, using, or > even collaborating with development. In that case, there are a large > number of unfamiliar looking files installed in my home directory, so > it's not always immediately obvious where files have come from. Those will not be symlinks, though. So all you get is "is this in any repo", not "what program does that belong to". Personally, I like to run temp stuff under a temp user, simply linking the .Xauthority between the two. That avoids hacks like kdesu. > To clarify, I'm thinking of using dvcs-autosync in parallel with mr, > not instead of it. Then I can't comment as I don't know what it does. > I don't know vcsh well enough to know which tool you are referring to > or what it would hide. But I can't see how an approach which (in my > very limited understanding) is based on altering environment variables > would work without requiring a restart of my editor. If you're a vim > user who starts up your editor every time you edit a new file, that > will work fine for you. But it doesn't gel with my personal workflow. :!vcsh run vim git commit -a > Not if there's a bullet-proof barrier in between your gun and your > foot :-) Which is exactly my point - I'm saying that if you had the > same (relative) file path in two different stow packages, stow will > refuse to install one over the top of the other; instead it will tell > you that you're trying to do something stupid. It might deflect into your groin ;) vcsh will fetch the files from the remote repo, run ls-files to see if there are any conflicts and only if there are not will it merge. If there is a conflict it will error out and tell you to fix it by hand. > I meant disadvantages to using symlinks in general. It doesn't really > matter what method you use for managing symlinks, the end result is > pretty much the same (modulo tree folding). Well, if you symlink a directory and enter that directory, you will get strange effects. Sane shells like zsh will try to prevent surprises, but session restoration after logging in again (think konsole, etc) will make you end up in the real directory, not the symlink. Icky. > - An accidental "rm ~/.zshrc" seems much more likely than an > accidental Agreed, but in that case, both models can restore in the blink of an eye. I was disregarding that as it's easy to fix. Losing your repo is not (for you). And no, it's not likely, but you asked for possible downsides :) > And in > the former case, if you are using symlinks, all you lose is a > symlink, whereas with detached git working directories, you lose > the whole file which may contain changes not yet in the git index > or repo. Agreed. Richard ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
Adam Spiers wrote: > So far mr is clearly winning :-) However, cfgctl does have one or two > tricks up its sleeve: > > - Config modules / packages / repositories / whatever you want to > call them are indexed by name within a unique namespace, rather > than by directory path, and packages are grouped together into > sections. This allows you to easily run any of the actions on: > > - all the packages (just like running mr from $HOME) > > - a single package, just by specifying its name without needing > to know where it lives, e.g. "cfgctl --update zsh" would > update just the zsh repository > > - a section (i.e. group of packages) just by specifying its name > (e.g. "CLI" or "mail" or "Xorg") without needing to know where > anything lives, e.g. "cfgctl --pull Xorg" would update all > repos containing config relating to my Xorg (previously X11) > environment > > - any packages matching a regular expression e.g. > "cfgctl --update /emacs/" Having two namespaces for the same thing does not strike me as necessarily a good idea. But if you wanted to do that with mr, you could maybe take advantage of a little-known thing it does with determining the absolute path: joey@gnu:~>mkdir namespace joey@gnu:~>cd namespace joey@gnu:~/namespace>ln -s ~/lib/sound joey@gnu:~/namespace>ln -s ~/src/git-annex joey@gnu:~/namespace>cd git-annex joey@gnu:~/namespace/git-annex>mr update mr update: /home/joey/src/git-annex The only problem with this approach is that it only work when inside the symlinked directory, so mr update in ~/namespace won't update the directories symlinked to there. > All in all, I feel that mr has a better design than cfgctl, and has > greater longevity. So last night I spent an hour or two doing a quick > proof of concept, to see whether I could extend mr to implement the > functionality I require, in particular the integration with GNU stow. > I'm pleased to say that so far it's looking very promising :-) > This is pretty much all that's needed: This seems close to something I could put in mr as an includable library. Could use some documentation though. -- see shy jo signature.asc Description: Digital signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: to symlink or not to symlink (was: Re: various suggestions for mr)
On Fri, Oct 28, 2011 at 4:09 PM, Richard Hartmann wrote: > On Fri, Oct 28, 2011 at 16:14, Adam Spiers wrote: > > FYI: My version of vcsh [1] is different from madduck's. He graciously > agreed to let me have the name and may switch over to my > re-implementation soon from what I heard from him. Ah thanks, I did wonder about that. >> (a) Are your ~/.* files symlinks or not? > > Not any more. > >> (b) Why? > > It seems unclean, at best. I generally try to avoid symlinks where > possible. There are very valid use cases for links (soft: git-annex, > hard: some backup schemes, sharing funny pics etc on shared disks, > cloning a directory to work with it iin git-annex while keeping the > old directory full intact...) but this is not one, imo. > > It comes down to preference. Sure, there's no right and wrong. It sounds like your preference is based on a sense of aesthetics rather than more concrete technical arguments? Not that there's anything wrong with that - aesthetics are important too. But if you are aware of some specific technical advantages of avoiding symlinks, I'd be very interested to hear them so that I can weigh them up against the alternative. >> - You can immediately see which files under ~ are managed by it. > > for repo in vcsh list; do vcsh run repo git ls-files; done > > Alias that away in case that's a valid use case, for you. Sure, although that's assuming you have a shell to hand. Almost always the case, but sometimes it's handy to be able to see with nothing more than a file manager (e.g. sftp). More significantly, it doesn't tell you which files are *not* managed by it. Without symlinks, you have to iterate over all your repositories, and then filter out those files from the set of files you are interested in looking at. >> - You can immediately see which stow package any symlinked file >> under ~ belongs to, e.g. > > See above. But I sincerely doubt that my .vimrc will ever end up in my > zsh repo. Well, I'm obviously more prone to mistakes than you ;-) But that aside, I want this setup to support checkout of a large number of third party software packages which I'm either trying out, using, or even collaborating with development. In that case, there are a large number of unfamiliar looking files installed in my home directory, so it's not always immediately obvious where files have come from. >> - No extra effort required to prevent other tools such as >> dvcs-autosync getting confused by having unrelated files in the >> working directory. > > Never heard of that, I use mr. And vcsh was written with mr in mind. > Thus, it integrates nicely. To clarify, I'm thinking of using dvcs-autosync in parallel with mr, not instead of it. >> - No need to use something like vcsh to temporarily and manually >> adjust git environment variables to point the correct bare repo >> (and this approach doesn't work anyway if you like to commit from >> within a long-running editor process). > > How is that a disadvantage when a tool hides it from you? I don't know vcsh well enough to know which tool you are referring to or what it would hide. But I can't see how an approach which (in my very limited understanding) is based on altering environment variables would work without requiring a restart of my editor. If you're a vim user who starts up your editor every time you edit a new file, that will work fine for you. But it doesn't gel with my personal workflow. >> - Highlights file conflicts between packages which could otherwise >> cause confusion. > > Again, shooting your own foot will always end up in a shot foot. Not if there's a bullet-proof barrier in between your gun and your foot :-) Which is exactly my point - I'm saying that if you had the same (relative) file path in two different stow packages, stow will refuse to install one over the top of the other; instead it will tell you that you're trying to do something stupid. >> - Ties in nicely with the UNIX way of one tool per job: mr manages >> the layer of interaction with "upstream" repositories, and >> integrates via action hooks with the symlink manager which manages >> the local "package" layer. > > So does vcsh. Yeah, I admit that one wasn't a very strong argument against not having symlinks :) >> But I'm sure there are some disadvantages too. Anyone care to >> elaborate? > > I did not look at stow, so no idea. I meant disadvantages to using symlinks in general. It doesn't really matter what method you use for managing symlinks, the end result is pretty much the same (modulo tree folding). > One point, though: If i delete my repos, my system continues to work > as expected. If you do the same, all your configs are gone. If I did something that stupid, I'd prefer to know about it sooner rather than later :-) Besides: - An accidental "rm ~/.zshrc" seems much more likely than an accidental rm -rf ~/path/to/all/my/git/repos/I/rarely/access/directly because my
Re: to symlink or not to symlink (was: Re: various suggestions for mr)
mumble.. [1] https://github.com/RichiH/vcsh ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: to symlink or not to symlink (was: Re: various suggestions for mr)
On Fri, Oct 28, 2011 at 16:14, Adam Spiers wrote: FYI: My version of vcsh [1] is different from madduck's. He graciously agreed to let me have the name and may switch over to my re-implementation soon from what I heard from him. > (a) Are your ~/.* files symlinks or not? Not any more. > (b) Why? It seems unclean, at best. I generally try to avoid symlinks where possible. There are very valid use cases for links (soft: git-annex, hard: some backup schemes, sharing funny pics etc on shared disks, cloning a directory to work with it iin git-annex while keeping the old directory full intact...) but this is not one, imo. It comes down to preference. > I get the impression that some people on this list prefer to use git's > detached working trees feature, e.g. Correct. > - You can immediately see which files under ~ are managed by it. for repo in vcsh list; do vcsh run repo git ls-files; done Alias that away in case that's a valid use case, for you. > - You can immediately see which stow package any symlinked file > under ~ belongs to, e.g. See above. But I sincerely doubt that my .vimrc will ever end up in my zsh repo. That would be stupid and shooting my own foot will always be possible. And yes, always have one repo per program. I even split up git & gitk... > - Zero issues with .gitignore Agreed, but my version of vcsh will fix that soonish. > - No extra effort required to prevent other tools such as > dvcs-autosync getting confused by having unrelated files in the > working directory. Never heard of that, I use mr. And vcsh was written with mr in mind. Thus, it integrates nicely. > - No need to use something like vcsh to temporarily and manually > adjust git environment variables to point the correct bare repo > (and this approach doesn't work anyway if you like to commit from > within a long-running editor process). How is that a disadvantage when a tool hides it from you? > - Highlights file conflicts between packages which could otherwise > cause confusion. Again, shooting your own foot will always end up in a shot foot. > - Ties in nicely with the UNIX way of one tool per job: mr manages > the layer of interaction with "upstream" repositories, and > integrates via action hooks with the symlink manager which manages > the local "package" layer. So does vcsh. > But I'm sure there are some disadvantages too. Anyone care to > elaborate? I did not look at stow, so no idea. One point, though: If i delete my repos, my system continues to work as expected. If you do the same, all your configs are gone. Richard ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Fri, Oct 28, 2011 at 3:26 PM, Dieter Plaetinck wrote: > You wrote "However I might very well want to manually place other > files inside ~/local which have nothing to do with stow". > > Now you wrote "As far as I'm aware, all my files are nicely > separated into appropriate packages". > > That confuses me. I was responding to your approach in which you > describe how you make stow unfold by creating a dummy 'antifold' > package which would allow you store files not managed by stow in > your ~/local Ah, I see! Well, in an ideal world, I would have time to ensure that every single file in my home directory is perfectly managed as a stow package :-) But in practice is there anyone who really achieves that? There are many cases where it just isn't worth the effort. Perhaps ~/local was a bad example, because that path is suggestive of a typical GNU-like installation sequence: ./configure --prefix=~/local make install in which case I agree it's not much more effort to do: ./configure --prefix=~/.stow/$pkgname make install # now install via stow but there are plenty of other examples where it is not pragmatic to spend the time ensuring every single file is controlled by stow, e.g. ./configure --prefix=~ make install# this puts some files in ~/doc # days/weeks/months later: emacs ~/doc/shopping-list.txt Without a ~/doc/.no-stow-folding file present, suddenly you have accidentally put your shopping list inside a third party piece of software :-) And it's not worth having a stow package for a shopping list which will probably be deleted tomorrow anyway. Another approach would be to add an option to stow that disables tree folding entirely; it shouldn't be hard to do that. But personally I find tree folding useful as long as it's managed well. ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: to symlink or not to symlink (was: Re: various suggestions for mr)
On Fri, Oct 28, 2011 at 03:14:38PM +0100, Adam Spiers wrote: > So with the direction this subthread is going, it seems a good time > to ask everyone: > >(a) Are your ~/.* files symlinks or not? >(b) Why? I symlink for reasons similar to what you gave: - Immediately know what is managed - Immediately know what is not Also, I was unfamiliar with fake-bare git repos and not completely confortable with git. I didn't have the time to investigate everything, so I stuck with what I knew already. If I was to change my setup (and I might while stuck inside during winter) I'd probably use fake-bare repositories, simply because I'm more familiar with the tools now. > - You can immediately see which stow package any symlinked file > under ~ belongs to, e.g. I hadn't heard of `stow` before, though I wish I had. I wrote my own alternative as a bash script. The only thing that mine does that `stow` doesn't seem to is the ability to stick a .linkdir file in certain directories to have the entire dir linked, instead of individual files within it. If anybody is curious, the code is on gitorious. Note that this script is full of horrible, horrible examples of things you shouldn't do. But since I wrote it while half-asleep, and it "works for me", I've never seen a need to fix it. https://gitorious.org/chrisirwin-utils/home-repos/blobs/master/recursive-ln > But I'm sure there are some disadvantages too. Anyone care to > elaborate? Sometimes symlinks can be overwritten with files. My script above informs me of those, and I get an email from cron with the conflicts for me to manually fix. Rare, but a pain. -- Chris Irwin e: ch...@chrisirwin.ca w: http://chrisirwin.ca ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Fri, 28 Oct 2011 15:00:52 +0100 Adam Spiers wrote: > On Fri, Oct 28, 2011 at 2:43 PM, Dieter Plaetinck > wrote: > > On Fri, 28 Oct 2011 14:34:16 +0100 > > Adam Spiers wrote: > >> However I might very well want to manually place other files inside > >> ~/local which have nothing to do with stow, let alone the 'foo' > >> stow package. It might make sense to have ~/local/lib/perl/Acme/ > >> be a symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks > >> higher up the tree would be undesirable. This is easily overcome > >> by creating a special stow package (which I call 'ANTIFOLD') > > > > this seems a bit messy though. Once you go the way of having a tool > > automagically manage all your symlinks, why not just have the > > discipline to put all your files in appropriate packages? so that > > you never _need_ to create "antifold" packages? what you're doing > > seems a bit like running into the opposite direction. > > I don't understand what you mean; please could you elaborate? > As far as I'm aware, all my files are nicely separated into > appropriate packages, but that doesn't solve the problem. You wrote "However I might very well want to manually place other files inside ~/local which have nothing to do with stow". Now you wrote "As far as I'm aware, all my files are nicely separated into appropriate packages". That confuses me. I was responding to your approach in which you describe how you make stow unfold by creating a dummy 'antifold' package which would allow you store files not managed by stow in your ~/local Dieter ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
to symlink or not to symlink (was: Re: various suggestions for mr)
So with the direction this subthread is going, it seems a good time
to ask everyone:
(a) Are your ~/.* files symlinks or not?
(b) Why?
I get the impression that some people on this list prefer to use git's
detached working trees feature, e.g.
http://www.mail-archive.com/vcs-home@lists.madduck.net/msg00078.html
so I'm interested to understand the reasons behind this preference.
As I see it, the benefits of using a symlink manager like GNU stow
are:
- You can immediately see which files under ~ are managed by it.
- You can immediately see which stow package any symlinked file
under ~ belongs to, e.g.
lrwxrwxrwx. 1 adam adam 21 Oct 20 10:20 /home/adam/.zshrc ->
.cfg/shell-env/.zshrc
- Zero issues with .gitignore
- No extra effort required to prevent other tools such as
dvcs-autosync getting confused by having unrelated files in the
working directory.
- No need to use something like vcsh to temporarily and manually
adjust git environment variables to point the correct bare repo
(and this approach doesn't work anyway if you like to commit from
within a long-running editor process).
- Highlights file conflicts between packages which could otherwise
cause confusion.
- Ties in nicely with the UNIX way of one tool per job: mr manages
the layer of interaction with "upstream" repositories, and
integrates via action hooks with the symlink manager which manages
the local "package" layer.
But I'm sure there are some disadvantages too. Anyone care to
elaborate?
Cheers,
Adam
On Fri, Oct 28, 2011 at 2:34 PM, Adam Spiers wrote:
> On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck
> wrote:
>> Sorry that I go slightly off-topic but you mentioned Gnu Stow, I looked it
>> up and it seems very nice.
>> i haven't run it yet, but (for those who don't want to read the long
>> description) from the description it seems like a simple and elegant tool,
>> which you give a directory ("i want symlinks here") and a bunch of package
>> directories ("all files in here must be symlinked")
>> and it will do the right thing on package additions and removals.
>
> Yes, it is pretty nice (although the code base is very old-fashioned).
>
> One thing it does which I guess other symlink managers wouldn't, is
> called "tree folding" - i.e. it makes intelligent decisions about when
> to symlink to a subdirectory vs. to individual files within that
> subtree:
>
> http://www.gnu.org/software/stow/manual.html#SEC4
>
> For example, imagine I have a stow package called 'foo' which wants to
> install a file to ~/local/lib/perl/Acme/Foo.pm (by "install", I mean
> set up a symlink so that that path points to the Foo.pm inside the
> stow package). If ~/local doesn't already exist, and 'foo' is the
> only stow package which installs anywhere under ~/local, then stow's
> tree folding feature will ensure that ~/local is a symlink back to
> $STOW_DIR/foo/local/lib/perl/Acme/Foo.pm.
>
> However I might very well want to manually place other files inside
> ~/local which have nothing to do with stow, let alone the 'foo' stow
> package. It might make sense to have ~/local/lib/perl/Acme/ be a
> symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up
> the tree would be undesirable. This is easily overcome by creating a
> special stow package (which I call 'ANTIFOLD') which contains (empty)
> dummy files called .no-stow-folding in those trees. So I run a simple
> little custom shell script:
>
> $ unfold ~/local/lib/perl5
>
> which creates an empty file
>
> $STOW_DIR/ANTIFOLD/local/lib/perl5/.no-stow-folding
>
> and (re)installs the 'ANTIFOLD' stow package, which causes stow to
> automatically "split" the ~/local/lib/perl5 tree open so that
>
> ~/local/
> ~/local/lib/
> ~/local/lib/perl5/
>
> are all normal directories, and ~/local/lib/perl5/Acme becomes the
> symlink. Problem solved!
>
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Fri, Oct 28, 2011 at 2:43 PM, Dieter Plaetinck wrote:
> On Fri, 28 Oct 2011 14:34:16 +0100
> Adam Spiers wrote:
>
>> On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck
>> wrote:
>> > Sorry that I go slightly off-topic but you mentioned Gnu Stow, I
>> > looked it up and it seems very nice. i haven't run it yet, but (for
>> > those who don't want to read the long description) from the
>> > description it seems like a simple and elegant tool, which you give
>> > a directory ("i want symlinks here") and a bunch of package
>> > directories ("all files in here must be symlinked") and it will do
>> > the right thing on package additions and removals.
>>
>> Yes, it is pretty nice (although the code base is very old-fashioned).
>>
>> One thing it does which I guess other symlink managers wouldn't, is
>> called "tree folding" - i.e. it makes intelligent decisions about when
>> to symlink to a subdirectory vs. to individual files within that
>> subtree:
>>
>> http://www.gnu.org/software/stow/manual.html#SEC4
>
> IMHO this feature is just common sense and it's among the first things
> I think of when I'm thinking "what would I want a symlink manager to do?",
> so I would expect that people who implement symlink managers either
> also do something like this, or at least list it as a todo.
>
>> For example, imagine I have a stow package called 'foo' which wants to
>> install a file to ~/local/lib/perl/Acme/Foo.pm (by "install", I mean
>> set up a symlink so that that path points to the Foo.pm inside the
>> stow package). If ~/local doesn't already exist, and 'foo' is the
>> only stow package which installs anywhere under ~/local, then stow's
>> tree folding feature will ensure that ~/local is a symlink back to
>> $STOW_DIR/foo/local/lib/perl/Acme/Foo.pm.
>
> Don't you mean to $STOW_DIR/foo/local ?
Yes, sorry :)
>> However I might very well want to manually place other files inside
>> ~/local which have nothing to do with stow, let alone the 'foo' stow
>> package. It might make sense to have ~/local/lib/perl/Acme/ be a
>> symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up
>> the tree would be undesirable. This is easily overcome by creating a
>> special stow package (which I call 'ANTIFOLD')
>
> this seems a bit messy though. Once you go the way of having a tool
> automagically
> manage all your symlinks, why not just have the discipline to put all your
> files
> in appropriate packages? so that you never _need_ to create "antifold"
> packages?
> what you're doing seems a bit like running into the opposite direction.
I don't understand what you mean; please could you elaborate?
As far as I'm aware, all my files are nicely separated into appropriate
packages, but that doesn't solve the problem.
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Fri, 28 Oct 2011 14:34:16 +0100
Adam Spiers wrote:
> On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck
> wrote:
> > Sorry that I go slightly off-topic but you mentioned Gnu Stow, I
> > looked it up and it seems very nice. i haven't run it yet, but (for
> > those who don't want to read the long description) from the
> > description it seems like a simple and elegant tool, which you give
> > a directory ("i want symlinks here") and a bunch of package
> > directories ("all files in here must be symlinked") and it will do
> > the right thing on package additions and removals.
>
> Yes, it is pretty nice (although the code base is very old-fashioned).
>
> One thing it does which I guess other symlink managers wouldn't, is
> called "tree folding" - i.e. it makes intelligent decisions about when
> to symlink to a subdirectory vs. to individual files within that
> subtree:
>
> http://www.gnu.org/software/stow/manual.html#SEC4
IMHO this feature is just common sense and it's among the first things
I think of when I'm thinking "what would I want a symlink manager to do?",
so I would expect that people who implement symlink managers either
also do something like this, or at least list it as a todo.
> For example, imagine I have a stow package called 'foo' which wants to
> install a file to ~/local/lib/perl/Acme/Foo.pm (by "install", I mean
> set up a symlink so that that path points to the Foo.pm inside the
> stow package). If ~/local doesn't already exist, and 'foo' is the
> only stow package which installs anywhere under ~/local, then stow's
> tree folding feature will ensure that ~/local is a symlink back to
> $STOW_DIR/foo/local/lib/perl/Acme/Foo.pm.
Don't you mean to $STOW_DIR/foo/local ?
>
> However I might very well want to manually place other files inside
> ~/local which have nothing to do with stow, let alone the 'foo' stow
> package. It might make sense to have ~/local/lib/perl/Acme/ be a
> symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up
> the tree would be undesirable. This is easily overcome by creating a
> special stow package (which I call 'ANTIFOLD')
this seems a bit messy though. Once you go the way of having a tool
automagically
manage all your symlinks, why not just have the discipline to put all your files
in appropriate packages? so that you never _need_ to create "antifold" packages?
what you're doing seems a bit like running into the opposite direction.
Dieter
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
On Fri, Oct 28, 2011 at 12:40 PM, Dieter Plaetinck wrote:
> Sorry that I go slightly off-topic but you mentioned Gnu Stow, I looked it up
> and it seems very nice.
> i haven't run it yet, but (for those who don't want to read the long
> description) from the description it seems like a simple and elegant tool,
> which you give a directory ("i want symlinks here") and a bunch of package
> directories ("all files in here must be symlinked")
> and it will do the right thing on package additions and removals.
Yes, it is pretty nice (although the code base is very old-fashioned).
One thing it does which I guess other symlink managers wouldn't, is
called "tree folding" - i.e. it makes intelligent decisions about when
to symlink to a subdirectory vs. to individual files within that
subtree:
http://www.gnu.org/software/stow/manual.html#SEC4
For example, imagine I have a stow package called 'foo' which wants to
install a file to ~/local/lib/perl/Acme/Foo.pm (by "install", I mean
set up a symlink so that that path points to the Foo.pm inside the
stow package). If ~/local doesn't already exist, and 'foo' is the
only stow package which installs anywhere under ~/local, then stow's
tree folding feature will ensure that ~/local is a symlink back to
$STOW_DIR/foo/local/lib/perl/Acme/Foo.pm.
However I might very well want to manually place other files inside
~/local which have nothing to do with stow, let alone the 'foo' stow
package. It might make sense to have ~/local/lib/perl/Acme/ be a
symlink to $STOW_DIR/foo/local/lib/perl/Acme/, but symlinks higher up
the tree would be undesirable. This is easily overcome by creating a
special stow package (which I call 'ANTIFOLD') which contains (empty)
dummy files called .no-stow-folding in those trees. So I run a simple
little custom shell script:
$ unfold ~/local/lib/perl5
which creates an empty file
$STOW_DIR/ANTIFOLD/local/lib/perl5/.no-stow-folding
and (re)installs the 'ANTIFOLD' stow package, which causes stow to
automatically "split" the ~/local/lib/perl5 tree open so that
~/local/
~/local/lib/
~/local/lib/perl5/
are all normal directories, and ~/local/lib/perl5/Acme becomes the
symlink. Problem solved!
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: various suggestions for mr
Sorry that I go slightly off-topic but you mentioned Gnu Stow, I looked it up
and it seems very nice.
i haven't run it yet, but (for those who don't want to read the long
description) from the description it seems like a simple and elegant tool,
which you give a directory ("i want symlinks here") and a bunch of package
directories ("all files in here must be symlinked")
and it will do the right thing on package additions and removals.
Some people have actually already written symlink-managers, probably not
knowing Stow existed.
So yeah, looks neat.
Carry on the discussion now :)
Dieter
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
various suggestions for mr
Hi all,
I've been tracking my dot files and related stuff since around 1999,
and was very excited to discover this mailing list two years ago.
Since then I've only been able to lurk, but finally have a bit of
spare time to participate.
Since 2005 I have been using my own (as yet unpublished) Perl suite
called "cfgctl" to manage my dot files, which serves a similar to
purpose to mr - applying operations such as "checkout", "update"
etc. to multiple repositories using multiple VCS backends. However
its shortcomings have increasingly irked me, and just when I was being
to resign myself to a complete rewrite, I noticed that mr had already
stolen most of my thunder :-)
The main differences between mr and cfgctl are:
- cfgctl's repository meta-data is written in pure Perl (and then
require'd at run-time) rather than one or more .INI-style
.mrconfig files. When I originally wrote it, needing
functionality akin to mr's "skip" parameter I naively thought that
this would give me maximum flexibility, and I mistakenly
underestimated the value of using a DSL.
- cfgctl only has a fixup hook (i.e. post-checkout/update), and no
hooks for any other actions.
- cfgctl is not nearly as extensible. It doesn't support writing
arbitrary new actions either globally or per repo.
- With hindsight cfgctl should have been made more shell-oriented in
general, because the kinds of tasks required for managing dot
files/repos, building/install packages etc. are much more easily
achieved in shell than in Perl.
- Adding support for a new VCS backend is more work in cfgctl,
because it requires writing a new Perl subclass of Cfg::Pkg::Base.
- cfgctl is harder to type than 'mr'.
So far mr is clearly winning :-) However, cfgctl does have one or two
tricks up its sleeve:
- Config modules / packages / repositories / whatever you want to
call them are indexed by name within a unique namespace, rather
than by directory path, and packages are grouped together into
sections. This allows you to easily run any of the actions on:
- all the packages (just like running mr from $HOME)
- a single package, just by specifying its name without needing
to know where it lives, e.g. "cfgctl --update zsh" would
update just the zsh repository
- a section (i.e. group of packages) just by specifying its name
(e.g. "CLI" or "mail" or "Xorg") without needing to know where
anything lives, e.g. "cfgctl --pull Xorg" would update all
repos containing config relating to my Xorg (previously X11)
environment
- any packages matching a regular expression e.g.
"cfgctl --update /emacs/"
- cfgctl integrates out of the box with GNU stow. Based on this
list's frequency of discussion on "fake bare" / detached git
repos, it seems that most people here have an aversion to the
symlink approach to managing dot files in $HOME. This surprises
me as I have been using them very successfully for 12 years,
although I will leave that debate for another thread.
- cfgctl's internals have a reasonable amount of pod / comments.
mr's code, whilst mostly self-explanatory at the high-level, does
have a few very long subroutines which I feel would gain clarity
by being refactored into some appropriately-named smaller subs.
All in all, I feel that mr has a better design than cfgctl, and has
greater longevity. So last night I spent an hour or two doing a quick
proof of concept, to see whether I could extend mr to implement the
functionality I require, in particular the integration with GNU stow.
I'm pleased to say that so far it's looking very promising :-)
This is pretty much all that's needed:
- 8< - 8< - 8< - 8< - 8< -
[DEFAULT]
lib =
STOW_DIR=$HOME/.cfg
STOW_TARGET=$HOME
MR_NAME="`basename $MR_REPO`"
#
set_stow_common_opts () {
STOW_PKG_PATH="$STOW_DIR/$MR_NAME"
stow_common_opts="-t $STOW_TARGET -d $STOW_DIR"
}
#
install () {
set_stow_common_opts
ensure_symlink_exists "$STOW_PKG_PATH" "${MR_REPO%/}"
}
#
ensure_symlink_exists () {
[ $# = 2 ] || error "CONFIG BUG: Usage: ensure_symlink_exists
SYMLINK TARGET"
symlink="$1"
required_target="$2"
if [ -L "$symlink" ]; then
actual_target="`readlink $symlink`"
if [ "$actual_target" = "$required_target" ]; then
return
else
error "Symlink $symlink already points to
$actual_target, cannot point to $required_target; aborting."
fi
fi
[ -e "$symlink" ] && error "Cannot create symlink $symlink -
already exists; aborting."
ln -s "$required_target" "$symlink"
}
#
stow () {
set_stow_common_opts
command stow $stow_common_opts "$MR_NAME"
}
restow () {
set_stow_co
