variables for plug-ins
Hi Dieter,
On Thu, Dec 1, 2011 at 8:12 AM, Dieter Plaetinck die...@plaetinck.be wrote:
On Thu, 1 Dec 2011 00:20:54 +
Adam Spiers vcs-h...@adamspiers.org wrote:
[shell-config]
checkout = git clone ...
stowable = true
Is this the right way to go? that mr plugins expose themselves by
introducing a new variable just to enable them? I think vcsh was
planning to do the same. Why not have a 'type' variable or
something which can be set to stow/vcsh/...
Thanks for the reply. Just to clarify, the plugin is first enabled by
the standard mechanism:
include = cat $plugins_dir/stow
but this only has any noticeable effect on any repository when you add
the 'stowable = true' line to it.
However, it does not make sense to think of this as setting the 'type'
of the repository, because it's possible for a repository to utilise
multiple plug-ins at the same time. For instance you could have a
repository which is stowable but is also retrieved via my 'download'
plugin. So the only sensible definition of the repository 'type' is
whichever vcs_test returns true for it (and the stow plug-in does not
add a new vcs_test).
By the way, my patch to add support for ${action}_append makes it
easier for multiple plug-ins to cooperate:
https://github.com/aspiers/kitenet-mr/commit/append
since they can all extend actions in different ways without
accidentally overriding each other's behaviour.
One other point: currently this stow plug-in works by treating
'stowable' as a new action. That's not great because it requires a
sub-invocation of mr. A more efficient way would be to write in the
mrconfig file:
lib = mr_stowable=yes
and then have the stow plug-in do [ -n $mr_stowable ] tests.
However this is much uglier to read and write than stowable = true.
Therefore what I would like to propose is a new special parameter
called something like 'variables', which lets you declare new
non-action parameters which would then be efficiently accessible by
any shell code that wants to use them. This would offer an easy way
to configure DEFAULT and per-repo behaviour for any given plug-in.
Plucking an example out of thin air, here's how you might configure
stow to use hard links for a particular repository instead of the
default of symlinks. The stow plugin would contain something like:
[DEFAULT]
variables_append =
stowable
stow_links_type
and the user's ~/.mrconfig would contain:
[DEFAULT]
stow_links_type = soft
...
[repo]
stowable = true
stow_links_type = hard
Does that sound reasonable?
___
vcs-home mailing list
vcs-home@lists.madduck.net
http://lists.madduck.net/listinfo/vcs-home
Re: variables for plug-ins
On Thu, 1 Dec 2011 11:47:41 + Adam Spiers vcs-h...@adamspiers.org wrote: Does that sound reasonable? FWIW I'm not too familiar with mr's internals, so I can't answer that question, but you seem to know what you're talking about :) Dieter ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
Re: new mr patches on their way (not quite ready yet though)
Adam Spiers wrote: I've made a lot of progress since this last mail, and I'm conscious that my branch is now approximately 50 commits ahead of the official master branch, so I think it's time to work on convergence if possible. It would be helpful if you: * separated the stow stuff into its own branch When adding a feature, I need something I can diff against; a chain of commits is ok, or a squashed commit is ok; a chain of commits mixed in with other unrelated changes is not * wrote commit messages that were longer than one line I need to understand a commit before I can apply it, and the choice is either that you type a little but more, or that I spend significant time guessing and likely miss something. A commit such as a2515e7e89f35c8d3291da9a5908b42a8d0bb277 is simple on its face, but is entirely lacking in an explanation of why the change was necessary; in what situation is there a dangling symlink and how did mr fail? Why is adding an error message of BUG: this shouldn't happen justified? Similarly, commit 655f0002ae80e21329ace97447a3a16c577949ec says it fixes a small bug, but neglects to say what the bug is. A commit such as 49163f09b8ff2c70c64076040be772b8d37c84aa or 1dd662640b946d681683c260f1b693cd0522b09f needs significant justification -- how does hardcoded VT100 color codes or a lot of different debug levels make mr better? Only a patch such as 96f2c8875bba4f7225decb60ee905815e2aeaa4a doesn't need more than one line of explanation. * avoid entangling different lines of development I was about to cherry-pick c4a8af985f525c2a1061576e72d526aa515151be until I noticed the last line ties it into the logging level stuff. Here's a summary of the main features of my branch: - A plug-in module for integration with the GNU Stow symlink manager, now well-tested and stable. I have recently become co-maintainer of GNU Stow, and its current git master branch and next official release contain enhancements which make it compatible with mr out-of-the-box. This makes tracking your $HOME dotfiles as easy as: [shell-config] checkout = git clone ... stowable = true Is there really no way to detect that a given repository is stowable by looking at the content of the repository or some other thing? Why not? - A plug-in module which allows tar balls / zip files etc. to be downloaded, unpacked, and used as repositories with minimal effort, e.g. [foo] checkout = mr_download_checkout http://example.com/foo.tar.bz2 A weird feature IMHO, but I use lib/* is sort of a contrib area and I'm willing to accept most any type of module into it. -- 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: new mr patches on their way (not quite ready yet though)
Adam Spiers wrote: Thanks for the reply. Sure - I can syphon those commits off into a stow branch. It bothered me too that they were non-contiguous. In fact, I appreciate that just dumping a whole load of uncategorised commits on your doorstep isn't particularly helpful, so maybe it's better if I create a branch for each change, and then point you at each branch. Would that work for you? There's no need for a separate branch for self-contained changes. Regarding color: well, I'm not sure on what level the question is asked, so forgive me if I'm treating a more technical question as a philosophical one ;-) If it's whether the use of color makes the program any more useful, then I guess it's a matter of individual taste, and I'm aware that some people don't like it. Each to their own, but personally I find that rather mystifying - after all, how many people do you know who use a web browser which renders everything in black and white? Or even within the terminal / CLI environment, how many people dislike the colors generated by ls(1) or git enough to go to the trouble of disabling them? I have not looked at the colors in use here, but IME adding color to terminal programs is often badly done, resulting in an angry fruit salad effect, and often needing additional configuration to disable it, or to tweak the colors to ones visible for colorblind users or users who cannot read yellow text on a white background. Which I can put up with in a mail reader, git diff, or a text editor, but given the very small amount of output done by mr, seems likely excessive. I suppose the idea is to pick out errors from amoung the rather larger amount of output displayed by the version control system, but mr already tries to structure its output to make it easy to do that. Regarding debug levels: without a more fine-grained approach to logging, it would have been too hard for me to understand mr's internals and achieve all the development I was able to. A large part of the challenge for me was understanding the order in which mr parsed / executed things etc. and the original -v was way too verbose to be able to trace this - it would have required me to keep too much stuff in my head at once. In fact, there were a few minor bugs which I spotted precisely because I entered this debugging exercise. Having said that, I freely admit that a debugging system based on numeric levels isn't particularly elegant or sophisticated, and I'd be happy to see something better. But it's a very standard technique industry-wide (c.f. syslog and hundreds of other logging software projects which use the concept of priorities or severities), and it was also The Simplest Thing That Could Possibly Work. I have never seen such a debugging system in which I did not use exactly two modes: none, or turn the dial to 11 and grep for the thing I actually wanted. Because it's up to the end user whether he wants to stow the repository or not, and that decision is entirely dependent on the context in which the repository is being used. But is there no way to tell if a repository is stowed? Why couldn't the checkout just handle registering it with stow (or whatever), and then the other actions could check to see if it was so registered. Wanting to use mr to manage the download and installation of a piece of software is weird? Or the implementation is weird? Wanting to use mr to manage software not in version control is weird. :) -- 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: new mr patches on their way (not quite ready yet though)
Adam Spiers wrote: OK. I'm not entirely sure I understand what you want though. How would you define self-contained in this context? Any patch that does not depend on any other patch. IMHO it's an impossible task without color. Scanning for a new paragraph (\n\n) is an impossible task? -- see shy jo signature.asc Description: Digital signature ___ vcs-home mailing list vcs-home@lists.madduck.net http://lists.madduck.net/listinfo/vcs-home
