On 04/28/2011 12:32 AM, Jon Seymour wrote: > On Thu, Apr 28, 2011 at 8:08 AM, Jonathan Nieder<jrnieder@xxxxxxxxx> wrote: >> Junio C Hamano wrote: > >> Or is the idea to blindly install (a symlink to) git-work to $(git >> --exec-path)/ rather than a place on the $PATH? In this case, I would >> be a little worried. How will the helper deal with uninstallation and >> with namespace conflicts? (On the $PATH, these are expected problems >> and I'd expect each user has some way of dealing with them already.) > > I see 'git pm activate' managing symbolic links in a directory > dedicated to the purpose (.e.g. ~/.git-pm/activated). > Why not just flip executable bits on commands in the git directory? That way, built-ins can't be disabled no matter what you type, and the list of out-of-core helpers will be kept shorter. Either way, the "activate" thing requires you to maintain state of downloaded extensions that aren't part of the core package. I'd say it's safe to assume that anything downloaded is supposed to be active and deactivating it is done by means of uninstalling it. > One thing 'git pm activate' could do is check that the commands > exported by the 'gitwork' descriptor do not conflict with what is > already activated. > > If the user has done something like: > > git clone https://repo/gitwork.git ~/hub/gitwork > > and then: > > git activate pm ~/hub/gitwork > > the symbolic links would be established to ~/hub/gitwork, wherever > that happens to be. > > If the user has done: > > apt-get install gitwork > > then given a package-manager adapter for apt-get, it could extract the > .gpm file from the list of installed files, and resume activation from > there. Ultimately, the end result is the same ~/.git-pm/activated is > updated, it has always been on the paths it needs to be. > > If the descriptor did have a list of exported commands (e.g. git-work, > git-base, git-atomic, git-test), then a global registry could use this > list of exported commands to detect conflicts early - at package > registration time which might help avoid grief down the track. But seriously. Don't you see how complex this is? If you want to make things easier for people, put up a website or a database somewhere and ship a (very, very small) addon with core git that just goes to fetch that list and present it to users upon request. The list should contain 3 fields and 3 fields only. 1. Short name of extension (must be unique) 2. Url for where to get the extension 3. Free-form text, containing info of why anyone would want to use it, preferrably in the style of git.git commit messages so the brief description is the first line and the full info comes later. Then your extension manager becomes really straightforward and can easily be extended over time to also uninstall applications. This assumes that git core itself can provide paths for where the user wants man-pages and whatnot, ofcourse, but such a patch is so trivial anyone who's seen code in any language can easily hack it up blindfolded. Even for versions that doesn't support it, the man- pages of any extension can be guessed from the --exec-path or just ignored and all of them put into /usr/share/man or whatever the path might be on the system we're on, so long as the extension manager remembers where they ended up. This could easily be handled by the extension itself creating a manifest file after it's done installing which is stashed away by the extension manager. A decent first step would be to have "git pm list" just show what extensions are available, what they do and where to get them. However, that info could just as easily be distributed to users by letting "git help" or something print a link to a wiki page and by letting extension devs know about some officially blessed way of installing and uninstalling extensions properly. Once all extensions use that same way and there are more than a small handful of extensions, the idea of having a script download and automagically install those extensions will probably be opened up again, but by then with more than a single user backing it up with a request that it be implemented (without showing any code). Shipping a bunch of extensions with git core or making distro package maintainers ship them as deactivated by default makes absolutely no sense what so ever. Shipping a (very small) extension manager with git that aids users obtaining more extensions makes sense when there's a proper flora of them rather than just a few. Either way, it's time to put your money where your mouth is and show us some code that does what you think is a good idea. If I were you, I'd start with the blindfolded patch mentioned above and then follow up with a configurable directory where git will search for additional commands, with a sensible default in the user's home directory (.git-plugins, perhaps?). Let conflicts go hang for now. They will be thoroughly frowned upon by the community anyway, since providing any sort of help for the command "git fniggle" will be totally impossible if there are 100 different implementations of it. With those two patches in place in core git (which I'm fairly sure Junio won't reject out of hand given his opinions in this thread), coding up the "make install" part of extensions become trivial and starting on the real extension manager becomes at least possible for both types of core git users, namely: 1. Those who get core git from yum/brew/apt-get 2. Those who build it from sources. -- Andreas Ericsson andreas.ericsson@xxxxxx OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html