{"thread":{"id":"27196","subject":"RFC: a plugin architecture for git extensions?","startedAt":"2011-04-27T03:36:44Z","lastAt":"2011-05-14T12:51:36Z","messageCount":105,"participants":["Jon Seymour","Jonathan Nieder","Junio C Hamano","Michael J Gruber","Motiejus Jakštys","Carlos Martín Nieto","Ævar Arnfjörð Bjarmason","Fredrik Gustafsson","Andreas Ericsson","Felipe Contreras","A Large Angry SCM","Drew Northup","Joey Hess","Pau Garcia i Quiles","david@lang.hm","David Aguilar","Jeff King","John Szakmeister","Miles Bader","Enrico Weigelt"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"166444","messageId":"BANLkTinh3v1o7t4HRwzZtFW--zu-j4U3kw@mail.gmail.com","threadId":"27196","inReplyTo":null,"subject":"RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T03:36:44Z","receivedAt":"2011-04-27T03:36:44Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"Has anyone ever given consideration to git supporting a plugin\narchitecture for git extensions?\n\nThe idea would be to provide a consistent way to install, and address\nextensions to the core git functionality in a manner that does not\nrequire the extension to actually be integrated into the git core.\n\nFor example, I have recently proposed a new command 'git work'\nhttps://github.com/jonseymour/git/blob/master/README.md which I think\nis a really useful extension to git.\n\nI haven't had much feedback for the concept. I am not sure if it is\nbecause people are too busy, just don't grok it, or grok it and don't\nthink it is useful.\n\nSo, perhaps it won't be included in git. That's fine, I can build my\nown fork of git which includes the proposed extension [ indeed, this\nis how I originally developed it]. That's fine for\nme, but it isn't the most practical way to distribute it to others\nsince I'll have to produce distribution packages for a variety of\ndifferent distribution formats or fallback to tars and zips.\n\nWhat would be call is if I could package my extension in a standard\nway and then anyone who was interested could simply do something like:\n\n git plugin install gitwork\n\nand then start using the commands as if they had built my fork of git\nthemselves.\n\njon.\n"},{"id":"166445","messageId":"20110427035825.GA4546@elie","threadId":"27196","inReplyTo":"BANLkTinh3v1o7t4HRwzZtFW--zu-j4U3kw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-27T03:58:25Z","receivedAt":"2011-04-27T03:58:25Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi Jon,\n\nJon Seymour wrote:\n\n> Has anyone ever given consideration to git supporting a plugin\n> architecture for git extensions?\n>\n> The idea would be to provide a consistent way to install, and address\n> extensions to the core git functionality in a manner that does not\n> require the extension to actually be integrated into the git core.\n\nI haven't looked into 'git work' yet, but for my own private tweaks,\ntwo mechanisms have sufficed:\n\n * adding a program named git-foo to the $PATH introduces a\n 'git foo' command. For the git command look and feel, scripts\n tend to start with\n\n\t. \"$(git --exec-path)\"/git-sh-setup\n\n (see git-sh-setup(1) for details).\n\n * various existing git commands can have their behavior modified\n through configuration and hooks.\n\nDoes 'git work' require changing the behavior of existing commands,\nand if so, are there hooks that could be introduced to help in doing\nthat?\n"},{"id":"166452","messageId":"BANLkTikUi5RKjgdmQHjg1-s0ND+ot4J3AA@mail.gmail.com","threadId":"27196","inReplyTo":"20110427035825.GA4546@elie","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T05:06:46Z","receivedAt":"2011-04-27T05:06:46Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wednesday, April 27, 2011, Jonathan Nieder wrote:\n> Hi Jon,\n>\n> I haven't looked into 'git work' yet, but for my own private tweaks,\n> two mechanisms have sufficed:\n>\n> * adding a program named git-foo to the $PATH introduces a\n> 'git foo' command. For the git command look and feel, scripts\n> tend to start with\n>\n> . \"$(git --exec-path)\"/git-sh-setup\n>\n> (see git-sh-setup(1) for details).\n>\n> * various existing git commands can have their behavior modified\n> through configuration and hooks.\n>\n> Does 'git work' require changing the behavior of existing commands,\n> and if so, are there hooks that could be introduced to help in doing\n> that?\n\ngit work is all new, so such considerations don't apply. Actually\nthere is one thing - I proposed a new config variable whose\ndescription I left out of the tar ball version because I didn\"t want\nto touch existing files in a git install. The other thing II needed to\ndo was include my man pages so they get picked up by git help.\n\nI can see that there might be a class of extension that 'enhances'\nexisting git commands. No doubt that would be a tricky problem to\nsolve and such a solution would not necessarily be good for the git\nplatform in any case.\n\n I guess one thing a git plugin architecture could do is provide\nmanagement of the PATH for plugins, a way to manage man pages and a\nway to manage plugin specific configuration help.\n\njon.\n\n| missed the list unintentionally, the first time through\n"},{"id":"166453","messageId":"7vwrig9ta7.fsf@alter.siamese.dyndns.org","threadId":"27196","inReplyTo":"BANLkTinh3v1o7t4HRwzZtFW--zu-j4U3kw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-27T05:07:12Z","receivedAt":"2011-04-27T05:07:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Seymour writes:\n\n> Has anyone ever given consideration to git supporting a plugin\n> architecture for git extensions?\n\nHint. The output from \"git help --all\" is produced by finding any\nexecutable whose name match \"git-*\" on your $PATH.\n\nSo if you have /home/js/bin on your $PATH, you can install your \"git-work\"\nscript as /home/js/bin/git-work, and that should be sufficient.\n"},{"id":"166454","messageId":"BANLkTinFX24gTR-0PK8Tyi5aOf8rnLk6Cg@mail.gmail.com","threadId":"27196","inReplyTo":"7vwrig9ta7.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T05:10:49Z","receivedAt":"2011-04-27T05:10:49Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wed, Apr 27, 2011 at 3:07 PM, Junio C Hamano wrote:\n> Jon Seymour writes:\n>\n>> Has anyone ever given consideration to git supporting a plugin\n>> architecture for git extensions?\n>\n> Hint.  The output from \"git help --all\" is produced by finding any\n> executable whose name match \"git-*\" on your $PATH.\n>\n> So if you have /home/js/bin on your $PATH, you can install your \"git-work\"\n> script as /home/js/bin/git-work, and that should be sufficient.\n>\n\nYep, that's a start, but does not a a complete plugin architecture make :-)\n\njon.\n"},{"id":"166455","messageId":"7vsjt49stq.fsf@alter.siamese.dyndns.org","threadId":"27196","inReplyTo":"BANLkTinFX24gTR-0PK8Tyi5aOf8rnLk6Cg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-27T05:17:05Z","receivedAt":"2011-04-27T05:17:05Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Seymour writes:\n\n>> So if you have /home/js/bin on your $PATH, you can install your \"git-work\"\n>> script as /home/js/bin/git-work, and that should be sufficient.\n>\n> Yep, that's a start, but does not a a complete plugin architecture make :-)\n\nPlease explain yourself.\n"},{"id":"166457","messageId":"BANLkTinRUaGmF5xqmVGWFurGMtO8Cgb9Hg@mail.gmail.com","threadId":"27196","inReplyTo":"7vsjt49stq.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T05:33:57Z","receivedAt":"2011-04-27T05:33:57Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"Hide quoted text -\nOn Wed, Apr 27, 2011 at 3:17 PM, Junio C Hamano wrote:\n> Jon Seymour writes:\n>\n>>> So if you have /home/js/bin on your $PATH, you can install your \"git-work\"\n>>> script as /home/js/bin/git-work, and that should be sufficient.\n>>\n>> Yep, that's a start, but does not a a complete plugin architecture make :-)\n>\n> Please explain yourself.\n>\n\nSo, I think at a very minimum, a plugin architecture should specify\nthe file system layout of packages to be managed by a plugin/package\nmanager.\n\nSo, where to find scripts, where to find man pages, bash completions,\nconfiguration help etc.\n\nA slightly more functional architecture would provide support for\nunpacking package archives into a \"standard\" repository location and\nfor removing unwanted plugins.\n\nA plugin architecture might specify a standard way to access\nextensions. (git blah is easy for local use, but what if a plugin\ngrabs a \"noun\" that the core wants to use that \"noun\" itself in\nfuture. Perhaps gitx blah would be a better standard way to access\nextensions. But that is an aside, I am sure this question has been\nconsidered previously).\n\nAn even more functional architecture would provide support for a\nglobal registry of plugins. I understand that git may not want to\nwrite its own package manager (how many times has that been done),\nbut it'd be nice if competing \"git package managers\" had a standard\ntarget to deploy to.\n\nMy thoughts about this are inspired by how the node project manages\npackages with its npm package manager and also the fact that I have\nseveral ideas on the boil at the moment that would definitely benefit\nfrom a standard way to manage these concerns.\n\njon.\n"},{"id":"166458","messageId":"BANLkTi=pjvf3hj53z1XoZU4Q_4nGzO+t+w@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTinRUaGmF5xqmVGWFurGMtO8Cgb9Hg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T05:37:23Z","receivedAt":"2011-04-27T05:37:23Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wed, Apr 27, 2011 at 3:33 PM, Jon Seymour wrote:\n> Hide quoted text -\n> On Wed, Apr 27, 2011 at 3:17 PM, Junio C Hamano wrote:\n>> Jon Seymour writes:\n>>\n>>>> So if you have /home/js/bin on your $PATH, you can install your \"git-work\"\n>>>> script as /home/js/bin/git-work, and that should be sufficient.\n>>>\n>>> Yep, that's a start, but does not a a complete plugin architecture make :-)\n>>\n>> Please explain yourself.\n>>\n>\n> So, I think at a very minimum, a plugin architecture should specify\n> the file system layout of packages to be managed by a plugin/package\n> manager.\n>\n> So, where to find scripts, where to find man pages, bash completions,\n> configuration help etc.\n>\n> A slightly more functional architecture would provide support for\n> unpacking package archives into a \"standard\" repository location and\n> for removing unwanted plugins.\n>\n> A plugin architecture might specify a standard way to access\n> extensions. (git blah is easy for local use, but what if a plugin\n> grabs a \"noun\" that the core wants to use that \"noun\" itself in\n> future. Perhaps gitx blah would be a better standard way to access\n> extensions. But that is an aside, I am sure this question has been\n> considered previously).\n>\n> An even more functional architecture would provide support for a\n> global registry of plugins. I understand that git may not want to\n> write its own package manager (how many times has that been done),\n> but it'd be nice if competing \"git package managers\" had a standard\n> target to deploy to.\n>\n> My thoughts about this are inspired by how the node project manages\n> packages with its npm package manager and also the fact that I have\n> several ideas on the boil at the moment that would definitely benefit\n> from a standard way to manage these concerns.\n>\n> jon.\n>\n\nAlso, a hypothetical git package manager might also provide build support\nfor packages to easy the creation of help, archives, validating\nlayouts and descriptors, etc.\n\njon.\n"},{"id":"166459","messageId":"7vk4eg9rsf.fsf@alter.siamese.dyndns.org","threadId":"27196","inReplyTo":"BANLkTinRUaGmF5xqmVGWFurGMtO8Cgb9Hg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-27T05:39:28Z","receivedAt":"2011-04-27T05:39:28Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Seymour writes:\n\n> My thoughts about this are inspired by how the node project manages\n> packages with its npm package manager and also the fact that I have\n> several ideas on the boil at the moment that would definitely benefit\n> from a standard way to manage these concerns.\n\nSounds like you have a plan ;-)\n\nIt would be ideal if you can arrange things so that the only thing the\nuser needs to do is to point your package manager to one subdirectory of\ncontrib/ and everything necessary would be installed...\n"},{"id":"166460","messageId":"BANLkTikiuBkF00WeanBV8X8JeooMReHcHA@mail.gmail.com","threadId":"27196","inReplyTo":"7vk4eg9rsf.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T05:42:02Z","receivedAt":"2011-04-27T05:42:02Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wed, Apr 27, 2011 at 3:39 PM, Junio C Hamano wrote:\n> Jon Seymour writes:\n>\n>> My thoughts about this are inspired by how the node project manages\n>> packages with its npm package manager and also the fact that I have\n>> several ideas on the boil at the moment that would definitely benefit\n>> from a standard way to manage these concerns.\n>\n> Sounds like you have a plan ;-)\n>\n> It would be ideal if you can arrange things so that the only thing the\n> user needs to do is to point your package manager to one subdirectory of\n> contrib/ and everything necessary would be installed...\n>\n>\n>\n>\n\nBy that you mean the contrib/ directory as the repository of\nextensions, with one such extension being the plugin manager itself?\n\njon.\n"},{"id":"166464","messageId":"BANLkTi=UafJRc76ePmVXo2gF+CNVnEL41Q@mail.gmail.com","threadId":"27196","inReplyTo":"7vk4eg9rsf.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T07:15:50Z","receivedAt":"2011-04-27T07:15:50Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wed, Apr 27, 2011 at 3:39 PM, Junio C Hamano wrote:\n> Jon Seymour writes:\n>\n>> My thoughts about this are inspired by how the node project manages\n>> packages with its npm package manager and also the fact that I have\n>> several ideas on the boil at the moment that would definitely benefit\n>> from a standard way to manage these concerns.\n>\n> Sounds like you have a plan ;-)\n>\n\nOk, here we go:\n\n https://github.com/jonseymour/gpm\n\nAnyone who violently objects to the suggested name of a package\nmanager interface - gpm, please speak up now because it'll be easier\nto change now.\n\n(And yes, gpm is intended to be an *interface*. The idea would be to\nallow the interface to be back-ended by different implementations\ndepending on taste, platform etc.).\n\nI suggest using this list for discussion, but I also think the github\nissue manager would be a pretty good option.\n\nSpeak up if, you see anything wrong so far!\n\njon.\n\nNAME\n====\ngpm - a package manager for git extensions\n\nDESCRIPTION\n===========\nThis is place holder for a proposed plugin architecture for git extensions.\n\nThe initial deliverable of the project will be a plugin architecture proposal.\nIn parallel to this deliverable a reference plugin manager will be developed.\n\nPRINCIPLES\n==========\n* define a repository layout specification\n* define a package descriptor (using the git config syntax)\n* package manager agnostic repo and package specifications\n * perhaps define a pluggable package manager interface\n* support for:\n * existing contrib/ directory\n * existing git patterns for finding and using extensions\n * man pages\n * package specific configuration help\n * bash completions\n * scripts\n* build support:\n * for documentation, archives\n* layers\n * repo, package descriptors\n * tool interface specifications\n * tool implementations\n * global package registry and repository\n\nINTENDED SCENARIOS\n==================\n\nInstallation and Removal\n------------------------\n\tgpm install package-name | package-url | package-archive\n\tgpm remove package-name\n\tgpm update package-name\n\tgpm list installed|available|active|inactive\n\tgpm status package-name\n\nActivation/De-activation\n------------------------\n\tgpm activate package-name\n\tgpm deactivate package-name\n\nMAILING LIST\n============\nUntil noted otherwise, please use the\n[http://dir.gmane.org/gmane.comp.version-control.git](git@vger.kernel.org)\nmailing list for discussions about design decisions. gpm: is suggested\na good prefix for such discussions. We might\nalso use the github issues manager to integrate and discuss\nsuggestions, subject to agreement from the list.\n\nAUTHOR\n======\nJon Seymour\n"},{"id":"166468","messageId":"4DB7CC7C.2050508@drmicha.warpmail.net","threadId":"27196","inReplyTo":"BANLkTi=UafJRc76ePmVXo2gF+CNVnEL41Q@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2011-04-27T07:57:48Z","receivedAt":"2011-04-27T07:57:48Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Jon Seymour venit, vidit, dixit 27.04.2011 09:15:\n> On Wed, Apr 27, 2011 at 3:39 PM, Junio C Hamano wrote:\n>> Jon Seymour writes:\n>>\n>>> My thoughts about this are inspired by how the node project manages\n>>> packages with its npm package manager and also the fact that I have\n>>> several ideas on the boil at the moment that would definitely benefit\n>>> from a standard way to manage these concerns.\n>>\n>> Sounds like you have a plan ;-)\n>>\n> \n> Ok, here we go:\n> \n> https://github.com/jonseymour/gpm\n> \n> Anyone who violently objects to the suggested name of a package\n> manager interface - gpm, please speak up now because it'll be easier\n> to change now.\n> \n> (And yes, gpm is intended to be an *interface*. The idea would be to\n> allow the interface to be back-ended by different implementations\n> depending on taste, platform etc.).\n> \n> I suggest using this list for discussion, but I also think the github\n> issue manager would be a pretty good option.\n> \n> Speak up if, you see anything wrong so far!\n\nI'm sorry to spoil the party before it started but I'm not very fond of\nhaving yet another package manager orthogonal to what distributions have\nalready. This is definitely not a way to get anything like that into a\ndistribution which has proper policies.\n\nWhat we could need now to help users is a working \"make -C contrib/foo\"\nto easily install selected features from our contrib area (with\n\"install\" or \"doc\" targets), i.e. set things up so that we can have very\nsimple makefiles in contrib (with an include).\n\nIf you really want to go forward with a bigger solution, we could\ndistribute \"extensions\" by installing but not \"activating\" them, and\nhave some command which activates them selectively (like hg extensions).\nThat is something distributions could ship, although I don't see any\nneed for it personally. Our architecture makes it so easy to \"integrate\"\ngit-foo, git-foo.1 and config variables without touching the core git\ninstallation at all!\n\nMichael\n"},{"id":"166470","messageId":"BANLkTinrU8LhA0RORde0e5a1TM5VB5gVNQ@mail.gmail.com","threadId":"27196","inReplyTo":"4DB7CC7C.2050508@drmicha.warpmail.net","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T08:15:37Z","receivedAt":"2011-04-27T08:15:37Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wed, Apr 27, 2011 at 5:57 PM, Michael J Gruber\n wrote:\n>\n> I'm sorry to spoil the party before it started but I'm not very fond of\n> having yet another package manager orthogonal to what distributions have\n> already. This is definitely not a way to get anything like that into a\n> distribution which has proper policies.\n\nI am happy to defer work on a full-blown package manager for now. I do\nagree, the world already has a surfeit of\npackage managers. As I say, I'd prefer a minimal interface that could\nbe back-ended by one or more of those if possible.\n\nInitially I'd like to focus on:\n\n* a descriptor format for packages providing hints about how to\nactivate an extension\n* guidelines for the filesystem layout of extensions themselves\n* a way to locally locate extensions that might be subject to activation\n* the interface between the git runtime and the activated package repository\n* the interface to activate/deactivate a locally located package\n\nI also want to avoid baking in any too many decisions about things\nlike registries and distribution models. That can come later.\n\njon.\n"},{"id":"166483","messageId":"BANLkTik8+ECdRsq19xUi1HzTnKoayvLOSw@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTinrU8LhA0RORde0e5a1TM5VB5gVNQ@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T08:40:07Z","receivedAt":"2011-04-27T08:40:07Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wed, Apr 27, 2011 at 6:15 PM, Jon Seymour wrote:\n> On Wed, Apr 27, 2011 at 5:57 PM, Michael J Gruber\n> wrote:\n>\n> I also want to avoid baking in any too many decisions about things\n> like registries and distribution models. That can come later.\n\nOk, may be some thoughts about a registry, at least to set a direction...\n\nI like the way brew on MAC OSX uses git to manage formulas managed in\na git repo.\n\nThe idea would be to maintain a registry of \"git package descriptors\".\nThe descriptors would be a copy of the whatever descriptor an\nactivated package would be described by, but probably simply a git\nconfig text file, since we already have the tools to parse those.\n\nSuch a descriptor would have hints about how to use a real package\nmanager to get the actual package, but would not actually contain any\nfiles from the package itself.\n\nSo, for example, the package source might be bundled in git-core\ncontrib/ directory, fetchable as a git repo, fetchable as a tar ball,\nfetchable as an apt-get package, as brew package etc. The idea is that\ngpm would know enough about invoking a real package manager to handle\nthe actual distribution details.\n\nOnce the package is installed by gpm, it is then subject to the local\nactivation process.\n\njon.\n"},{"id":"166490","messageId":"20110427093627.GH2709@jakstys.lt","threadId":"27196","inReplyTo":"BANLkTik8+ECdRsq19xUi1HzTnKoayvLOSw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Motiejus Jakštys","fromEmail":"desired.mta@gmail.com","sentAt":"2011-04-27T09:36:27Z","receivedAt":"2011-04-27T09:36:27Z","isPatch":false,"sender":{"key":"desired.mta@gmail.com","avatar":"https://gravatar.com/avatar/5d7d88e7b672acebe3472e92baccb5f933fbd282b6131e22e32d96e5818b5b38?d=mp&s=160"},"body":"On Wed, Apr 27, 2011 at 06:40:07PM +1000, Jon Seymour wrote:\n> On Wed, Apr 27, 2011 at 6:15 PM, Jon Seymour wrote:\n> > On Wed, Apr 27, 2011 at 5:57 PM, Michael J Gruber\n> > wrote:\n> >\n> The idea would be to maintain a registry of \"git package descriptors\".\n> The descriptors would be a copy of the whatever descriptor an\n> activated package would be described by, but probably simply a git\n> config text file, since we already have the tools to parse those.\n> \n> Such a descriptor would have hints about how to use a real package\n> manager to get the actual package, but would not actually contain any\n> files from the package itself.\n\n> \n> So, for example, the package source might be bundled in git-core\n> contrib/ directory, fetchable as a git repo, fetchable as a tar ball,\n> fetchable as an apt-get package, as brew package etc. The idea is that\n> gpm would know enough about invoking a real package manager to handle\n> the actual distribution details.\n\nLet me check If I get this right:\nSay I am a maintainer of enchanced git log -- git logx. It is one .c\nfile, which has to be simply compiled (cc -o git-logx logx.c).\n\nIf I want to maintain the package in a way you are suggesting, I have to\nprepare deb, rpm, tarball, zipball, brew (what ever it is, sorry for\nnon-intelligence) and what not. Otherwise, I lose users? *ball is not\nan option, since we are supporting different architectures and cannot\ndistribute compiled files (unless statically compiled for all\narchitectures we know, which is not good for obvious reasons).\n\nMorevoer, different debs for different debian releases (if package\ndepends on libc version)?\n\nAlthough this looks very nice from user point of view, it would be a\npain for the extension maintainer... Though it's only one C file.\n\nI think shipping it in contrib/ and having extension system is a better\noption. Though it leaves a hole for dependencies -- if my logx depends\non boost or imagemagick, we don't want make git depend on it...\n\nMotiejus\n"},{"id":"166493","messageId":"BANLkTi=UCGkQaOF7c0Ks6315gygacMzfyQ@mail.gmail.com","threadId":"27196","inReplyTo":"20110427093627.GH2709@jakstys.lt","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T09:59:33Z","receivedAt":"2011-04-27T09:59:33Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"2011/4/27 Motiejus Jakštys :\n> On Wed, Apr 27, 2011 at 06:40:07PM +1000, Jon Seymour wrote:\n>> On Wed, Apr 27, 2011 at 6:15 PM, Jon Seymour wrote:\n>> > On Wed, Apr 27, 2011 at 5:57 PM, Michael J Gruber\n>> > wrote:\n>> >\n>> The idea would be to maintain a registry of \"git package descriptors\".\n>> The descriptors would be a copy of the whatever descriptor an\n>> activated package would be described by, but probably simply a git\n>> config text file, since we already have the tools to parse those.\n>>\n>> Such a descriptor would have hints about how to use a real package\n>> manager to get the actual package, but would not actually contain any\n>> files from the package itself.\n>\n>>\n>> So, for example, the package source might be bundled in git-core\n>> contrib/ directory, fetchable as a git repo, fetchable as a tar ball,\n>> fetchable as an apt-get package, as brew package etc. The idea is that\n>> gpm would know enough about invoking a real package manager to handle\n>> the actual distribution details.\n>\n> Let me check If I get this right:\n> Say I am a maintainer of enchanced git log -- git logx. It is one .c\n> file, which has to be simply compiled (cc -o git-logx logx.c).\n>\n> If I want to maintain the package in a way you are suggesting, I have to\n> prepare deb, rpm, tarball, zipball, brew (what ever it is, sorry for\n> non-intelligence) and what not. Otherwise, I lose users? *ball is not\n> an option, since we are supporting different architectures and cannot\n> distribute compiled files (unless statically compiled for all\n> architectures we know, which is not good for obvious reasons).\n>\n> Morevoer, different debs for different debian releases (if package\n> depends on libc version)?\n>\n> Although this looks very nice from user point of view, it would be a\n> pain for the extension maintainer... Though it's only one C file.\n>\n\nI don't see why. You wouldn't be forced to maintain one of those\npackages, anymore than you\nare now. If you can, you just publish a git url, and your job is done.\nIf your tool requires\ncompilation, you have already solved the distribution problem for the\npackage managers you choose to support.\n\nAll I am suggesting you do is that you list pointers to these\npackages, which gpm could then use to actually do the installation for\nyou.\n\nThe thing I really care about is: once the package has been installed\nlocally, how do I activate it and makes its features available to the\ngit runtime, without having to futz around with my PATH, MANPATH etc?\n\nYes, this is user focused. I want users of my tool to be able to something like:\n\n git pm install gitwork\n\nor perhaps:\n\n git pm install git://github.com/jonseymour/gitwork\n\nAnd then start using it. I want the git completions to be there, I\nwant the man pages to be there. I want the scripts to be\nthere. In my case, there I really shouldn't have to do anything other\nthan point at a git url, get the package transported\nto a local directory and activate it.\n\nI want to tell my users what they need to do to install my extension\nwithout having to have variants of the instructions for zip/tar\npeople, apt-get people, brew people, MAC ports people, yum people etc.\nYes, for compiled stuff, someone has to prepare the packages. But once\nthey are prepared, use whatever package manager the user uses to\ninstall it and expose the gpm config required to activate it.\n\n> I think shipping it in contrib/ and having extension system is a better\n> option. Though it leaves a hole for dependencies -- if my logx depends\n> on boost or imagemagick, we don't want make git depend on it...\n>\n\nUnless I am misunderstanding something about how contrib/ is managed\nthat still requires Junio to be in the loop, which defeats one of my\nobjectives here - which is to allow anyone to contribute and share\ntheir own extensions without being bottlenecked by someone else's\nrelease cycle.\n\njon.\n"},{"id":"166496","messageId":"20110427102133.GA10057@bee.lab.cmartin.tk","threadId":"27196","inReplyTo":"BANLkTi=UafJRc76ePmVXo2gF+CNVnEL41Q@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Carlos Martín Nieto","fromEmail":"cmn@elego.de","sentAt":"2011-04-27T10:21:33Z","receivedAt":"2011-04-27T10:21:33Z","isPatch":false,"sender":{"key":"cmn@elego.de","avatar":"https://avatars.githubusercontent.com/u/335443?v=4"},"body":"On Wed, Apr 27, 2011 at 05:15:50PM +1000, Jon Seymour wrote:\n> On Wed, Apr 27, 2011 at 3:39 PM, Junio C Hamano wrote:\n> > Jon Seymour writes:\n> >\n> >> My thoughts about this are inspired by how the node project manages\n> >> packages with its npm package manager and also the fact that I have\n> >> several ideas on the boil at the moment that would definitely benefit\n> >> from a standard way to manage these concerns.\n> >\n> > Sounds like you have a plan ;-)\n> >\n> \n> Ok, here we go:\n> \n> https://github.com/jonseymour/gpm\n> \n> Anyone who violently objects to the suggested name of a package\n> manager interface - gpm, please speak up now because it'll be easier\n> to change now.\n\nI'm not objecting, but when I see gpm, I think of the mouse daemon for\nLinux virtual consoles[0] and whose git clone address also ends in gpm.\n\nI find a name like gem (git extension manager) nicer, though that's\ntaken by ruby.\n\n[0] http://www.nico.schottelius.org/software/gpm/\n\n cmn\n"},{"id":"166499","messageId":"BANLkTinzHi45wJRwHjhPOQGLXQDoTXu=bw@mail.gmail.com","threadId":"27196","inReplyTo":"20110427102133.GA10057@bee.lab.cmartin.tk","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T10:44:44Z","receivedAt":"2011-04-27T10:44:44Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":">\n> I'm not objecting, but when I see gpm, I think of the mouse daemon for\n> Linux virtual consoles[0] and whose git clone address also ends in gpm.\n>\n> I find a name like gem (git extension manager) nicer, though that's\n> taken by ruby.\n>\n> [0] http://www.nico.schottelius.org/software/gpm/\n>\n>   cmn\n>\n\nYes, I guess name clashes are not with out precedent, but perhaps we\nshould try harder this time or people will start to talk :-)\n\nHow about git-pm? I am thinking the script would be called git-pm\nanyway, so it would make sense.\n\njon.\n"},{"id":"166500","messageId":"20110427104856.GB7186@jakstys.lt","threadId":"27196","inReplyTo":"BANLkTi=UCGkQaOF7c0Ks6315gygacMzfyQ@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Motiejus Jakštys","fromEmail":"desired.mta@gmail.com","sentAt":"2011-04-27T10:48:56Z","receivedAt":"2011-04-27T10:48:56Z","isPatch":false,"sender":{"key":"desired.mta@gmail.com","avatar":"https://gravatar.com/avatar/5d7d88e7b672acebe3472e92baccb5f933fbd282b6131e22e32d96e5818b5b38?d=mp&s=160"},"body":"On Wed, Apr 27, 2011 at 07:59:33PM +1000, Jon Seymour wrote:\n> 2011/4/27 Motiejus Jakštys :\n> > On Wed, Apr 27, 2011 at 06:40:07PM +1000, Jon Seymour wrote:\n> > Although this looks very nice from user point of view, it would be a\n> > pain for the extension maintainer... Though it's only one C file.\n> >\n> \n> I don't see why. You wouldn't be forced to maintain one of those\n> packages, anymore than you are now. If you can, you just publish a git\n> url, and your job is done. If your tool requires compilation, you\n> have already solved the distribution problem for the package managers\n> you choose to support.\n> \n> All I am suggesting you do is that you list pointers to these\n> packages, which gpm could then use to actually do the installation for\n> you.\n> \n> The thing I really care about is: once the package has been installed\n> locally, how do I activate it and makes its features available to the\n> git runtime, without having to futz around with my PATH, MANPATH etc?\n> \n> Yes, this is user focused. I want users of my tool to be able to\n> something like:\n> \n> git pm install gitwork\n> \n> or perhaps:\n> \n> git pm install git://github.com/jonseymour/gitwork\n> \n> And then start using it. I want the git completions to be there, I\n> want the man pages to be there. I want the scripts to be there. In my\n> case, there I really shouldn't have to do anything other than point at\n> a git url, get the package transported to a local directory and\n> activate it.\n> \n> I want to tell my users what they need to do to install my extension\n> without having to have variants of the instructions for zip/tar\n> people, apt-get people, brew people, MAC ports people, yum people etc.\n> Yes, for compiled stuff, someone has to prepare the packages. But once\n> they are prepared, use whatever package manager the user uses to\n> install it and expose the gpm config required to activate it.\n\npython virtualenv has very similar goals and does the same thing, the\nonly difference is you have to \"source env/bin/activate\" before using\nyour local modules (or run env/bin/python). I can clarify what features\nfrom it could be used for git, if you like.\n\n> > I think shipping it in contrib/ and having extension system is a better\n> > option. Though it leaves a hole for dependencies -- if my logx depends\n> > on boost or imagemagick, we don't want make git depend on it...\n> >\n> \n> Unless I am misunderstanding something about how contrib/ is managed\n> that still requires Junio to be in the loop, which defeats one of my\n> objectives here - which is to allow anyone to contribute and share\n> their own extensions without being bottlenecked by someone else's\n> release cycle.\nYes, you are right. It shouldn't. Like in python.\n\nMotiejus\n"},{"id":"166501","messageId":"BANLkTimqVs+Bg+zz7xu1Fb=a_dJ65WOvQQ@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTinh3v1o7t4HRwzZtFW--zu-j4U3kw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2011-04-27T11:01:30Z","receivedAt":"2011-04-27T11:01:30Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Wed, Apr 27, 2011 at 05:36, Jon Seymour wrote:\n\n> What would be call is if I could package my extension in a standard\n> way and then anyone who was interested could simply do something like:\n>\n>    git plugin install gitwork\n>\n> and then start using the commands as if they had built my fork of git\n> themselves.\n\nWe already have a plugin system, you can drop \"git-work\" in your\n$PATH, what you're talking about is a packaging system, and solving\nthat problem in a user facing application like Git is IMNSHO a\nterrible idea.\n\nInstead you could just make gitwork available somewhere and then\ninstall it as:\n\n sudo aptitude install git-work\n\nOr whatever incarnation of that your distro or OS provides.\n\nHaving our own \"gpm\" system would mean having to solve all these\nissues of distribution, cross-platform & arch compatibility that real\npackaging systems already deal with.\n\nIf you *really* wanted to go through with this I'd suggest just using\nsome existing package manager like apt, aliasing it to \"gpm\", then\nconfigure it to download packages from your own custom repository, and\ninstall them in ~/ somewhere.\n\nYou'd still be re-inventing the wheel, but at least minimally so.\n"},{"id":"166502","messageId":"20110427113840.GF31730@paksenarrion.iveqy.com","threadId":"27196","inReplyTo":"BANLkTinRUaGmF5xqmVGWFurGMtO8Cgb9Hg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Fredrik Gustafsson","fromEmail":"iveqy@iveqy.com","sentAt":"2011-04-27T11:38:40Z","receivedAt":"2011-04-27T11:38:40Z","isPatch":false,"sender":{"key":"iveqy@iveqy.com","avatar":"https://avatars.githubusercontent.com/u/761743?v=4"},"body":"On Wed, Apr 27, 2011 at 03:33:57PM +1000, Jon Seymour wrote:\n> So, I think at a very minimum, a plugin architecture should specify\n> the file system layout of packages to be managed by a plugin/package\n> manager.\n\nAs I recall, Junios initial plan was to have gitk-git as a submodule at\nsome point. I still thinks this is a good idea.\n\nIf we extends the submodule concept, of not only having a list of\nsubmodules, but also state weather a submodule is 'active' or 'inactive'\nwe could easily get a _very_ customable git.git.\n\nImagine git.git only containing git. A 'git submodule init' would load\nthe default 'active' submodules (for example git-gui, gitk-gui and\ngitweb), everything in contrib is 'inactive'. The point here is to be\nable to ship references to nice things to have (contrib) but not force\nthe use (download, diskspace, etc.) of it.\n\nIf a user finds an other awesome \"plugin\" to use with git, it's easy to\nadd it to h{er,i}s repository with 'git submodule add'.\n\nOnce the code is downloaded to the git-workspace (via 'git submodule\nupdate') the git build system ('make') would take care of building and\ninstallation, just as it does today.\n\n-- \nMed vänliga hälsningar\nFredrik Gustafsson\n\ntel: 0733-608274\ne-post: iveqy@iveqy.com\n"},{"id":"166506","messageId":"BANLkTim=ARYu=E-Lgu8dA+FpVQUY+q-yeA@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTimqVs+Bg+zz7xu1Fb=a_dJ65WOvQQ@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T11:42:57Z","receivedAt":"2011-04-27T11:42:57Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":">\n> We already have a plugin system, you can drop \"git-work\" in your\n> $PATH, what you're talking about is a packaging system, and solving\n> that problem in a user facing application like Git is IMNSHO a\n> terrible idea.\n>\n> Instead you could just make gitwork available somewhere and then\n> install it as:\n>\n>    sudo aptitude install git-work\n>\n> Or whatever incarnation of that your distro or OS provides.\n>\n> Having our own \"gpm\" system would mean having to solve all these\n> issues of distribution, cross-platform & arch compatibility that real\n> packaging systems already deal with.\n>\n> If you *really* wanted to go through with this I'd suggest just using\n> some existing package manager like apt, aliasing it to \"gpm\", then\n> configure it to download packages from your own custom repository, and\n> install them in ~/ somewhere.\n>\n> You'd still be re-inventing the wheel, but at least minimally so.\n>\n\n\nNo. As I explained in the posts\n that you chose not to read, such concerns would be dealt with by real\npackage managers.\n\nOne you have read those posts, let me know if you still have concerns,\nhumble or otherwise.\n\njon.\n"},{"id":"166507","messageId":"BANLkTimUPGqVcn743P-Hkf_BaS9XT93=ZQ@mail.gmail.com","threadId":"27196","inReplyTo":"20110427113840.GF31730@paksenarrion.iveqy.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T11:57:51Z","receivedAt":"2011-04-27T11:57:51Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wednesday, April 27, 2011, Fredrik Gustafsson wrote:\n> On Wed, Apr 27, 2011 at 03:33:57PM +1000, Jon Seymour wrote:\n>> So, I think at a very minimum, a plugin architecture should specify\n>> the file system layout of packages to be managed by a plugin/package\n>> manager.\n>\n> As I recall, Junios initial plan was to have gitk-git as a submodule at\n> some point. I still thinks this is a good idea.\n>\n> If we extends the submodule concept, of not only having a list of\n> submodules, but also state weather a submodule is 'active' or 'inactive'\n> we could easily get a _very_ customable git.git.\n>\n> Imagine git.git only containing git. A 'git submodule init' would load\n> the default 'active' submodules (for example git-gui, gitk-gui and\n> gitweb), everything in contrib is 'inactive'. The point here is to be\n> able to ship references to nice things to have (contrib) but not force\n> the use (download, diskspace, etc.) of it.\n>\n> If a user finds an other awesome \"plugin\" to use with git, it's easy to\n> add it to h{er,i}s repository with 'git submodule add'.\n>\n> Once the code is downloaded to the git-workspace (via 'git submodule\n> update') the git build system ('make') would take care of building and\n> installation, just as it does today.\n>\n\nFrederiick,\n\nI have also been think about submodules as one possible back-end\npackage distribution manager, It certainly makes sense since once can\nat least assume git is available :-)\n\nHowever, it would be only one way, precisely because I will need to\nrely on real package managers tif he build step is non-trivial.\n\nAnyway, thanks for your feedback.\n\nJon.\n\n\n> --\n> Med vänliga hälsningar\n> Fredrik Gustafsson\n>\n> tel: 0733-608274\n> e-post: iveqy@iveqy.com\n>\n"},{"id":"166508","messageId":"4DB80747.8080401@op5.se","threadId":"27196","inReplyTo":"BANLkTinh3v1o7t4HRwzZtFW--zu-j4U3kw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-04-27T12:08:39Z","receivedAt":"2011-04-27T12:08:39Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 04/27/2011 05:36 AM, Jon Seymour wrote:\n> Has anyone ever given consideration to git supporting a plugin\n> architecture for git extensions?\n> \n> The idea would be to provide a consistent way to install, and address\n> extensions to the core git functionality in a manner that does not\n> require the extension to actually be integrated into the git core.\n> \n\nHorrible idea. There are already as many package managers as there\nare packages without us throwing another one into the mix.\n\n> For example, I have recently proposed a new command 'git work'\n> https://github.com/jonseymour/git/blob/master/README.md which I think\n> is a really useful extension to git.\n> \n> I haven't had much feedback for the concept. I am not sure if it is\n> because people are too busy, just don't grok it, or grok it and don't\n> think it is useful.\n> \n\nI had a look at the manpage. It seems to do more or less exactly what\nthe same command would do without the word \"work\" thrown in, so either\nit's quite useless or you've failed to describe its usefulness in the\nmanpage.\n\n\"git atomic\" seems nice though.\n\n> So, perhaps it won't be included in git. That's fine, I can build my\n> own fork of git which includes the proposed extension [ indeed, this\n> is how I originally developed it]. That's fine for\n> me, but it isn't the most practical way to distribute it to others\n> since I'll have to produce distribution packages for a variety of\n> different distribution formats or fallback to tars and zips.\n> \n\nWhat you can do is let your Makefile (or some other install-script)\ntake the destination path for \"make install\" (or equivalent) from\nthe output of \"git --exec-path\".\n\nThat way, you can ship \"git extadd\" or whatever you want to call it\nas a simple installer that installs executable and man-page in their\nproper locations. If the commands you install require configuration\nby default I'd say they're broken to begin with, but even that can\nbe remedied by running \"git config --add key value\" from the installer.\n\nSo in a way, git is already its own pkg-config binary and anyone\nclever enough to write useful scripts that enhances git will almost\ncertainly see that and use it from their favourite language quite\nwithout having to learn some new magic format for package management.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"166517","messageId":"BANLkTimUHrHqS-Ssj+mK=0T8QHKg34pkaw@mail.gmail.com","threadId":"27196","inReplyTo":"4DB80747.8080401@op5.se","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T12:50:04Z","receivedAt":"2011-04-27T12:50:04Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wednesday, April 27, 2011, Andreas Ericsson wrote:\n> On 04/27/2011 05:36 AM, Jon Seymour wrote:\n>> Has anyone ever given consideration to git supporting a plugin\n>> architecture for git extensions?\n>>\n>> The idea would be to provide a consistent way to install, and address\n>> extensions to the core git functionality in a manner that does not\n>> require the extension to actually be integrated into the git core.\n>>\n>\n\n> Horrible idea. There are already as many package managers as there\n> are packages without us throwing another one into the mix.\n>\n\nI agree that there are too many package managers. But do you know\nwhat? There isn't a single package manager that reliably works across\nplatform. apt-get? great. Except you need something else for Mac,\ncywgin, or, um Fedora. Brew? Fine then you only need to worry about\nLinux and cygwin. Cygwin? ...\n\nThe platform for my extension is git. Not Mac. Not Debian. Not Fedora.\nNot cygwin. git.\n\nThe lowest common denominator across these environments is, um, git.\n\nI challenge the sceptIcs to specify a one line command script that\nworks across all possible environment that is more succinct than:\n\n git pm install gitwork\n\nIt shouldn't be too hard. A tar command here, an enviroment variable\nedit there. Perhaps a curl command or a browser download.\n\nYou have 4 words. Knock yourself out.\n\n>> For example, I have recently proposed a new command 'git work'\n>> https://github.com/jonseymour/git/blob/master/README.md which I think\n>> is a really useful extension to git.\n>>\n>> I haven't had much feedback for the concept. I am not sure if it is\n>> because people are too busy, just don't grok it, or grok it and don't\n>> think it is useful.\n>>\n>\n> I had a look at the manpage. It seems to do more or less exactly what\n> the same command would do without the word \"work\" thrown in, so either\n> it's quite useless or you've failed to describe its usefulness in the\n> manpage.\n>\n\nIt is far from useless, so I have clearly failed with the explanation.\nI will post later,perhaps with some diagrams.\n\n> \"git atomic\" seems nice though.\n>\n\nThank you!\n\n>> So, perhaps it won't be included in git. That's fine, I can build my\n>> own fork of git which includes the proposed extension [ indeed, this\n>> is how I originally developed it]. That's fine for\n>> me, but it isn't the most practical way to distribute it to others\n>> since I'll have to produce distribution packages for a variety of\n>> different distribution formats or fallback to tars and zips.\n>>\n>\n> What you can do is let your Makefile (or some other install-script)\n> take the destination path for \"make install\" (or equivalent) from\n> the output of \"git --exec-path\".\n>\n> That way, you can ship \"git extadd\" or whatever you want to call it\n> as a simple installer that installs executable and man-page in their\n> proper locations. If the commands you install require configuration\n> by default I'd say they're broken to begin with, but even that can\n> be remedied by running \"git config --add key value\" from the installer.\n>\n> So in a way, git is already its own pkg-config binary and anyone\n> clever enough to write useful scripts that enhances git will almost\n> certainly see that and use it from their favourite language quite\n> without having to learn some new magic format for package management.\n>\n\nThose 3 paragraphs were substantially longer than 4 words. Again,\nthere is a tar ball, let me know how I can install it across alll\nenvironments that got runs on. Make sure the man pages work.\n\njon.\n\n\n> --\n> Andreas Ericsson                   andreas.ericsson@op5.se\n> OP5 AB                             www.op5.se\n> Tel: +46 8-230225                  Fax: +46 8-230231\n>\n> Considering the successes of the wars on alcohol, poverty, drugs and\n> terror, I think we should give some serious thought to declaring war\n> on peace.\n>\n"},{"id":"166519","messageId":"BANLkTikvwoCCmCofbVVPzmuA8uHxqATjTg@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTimUHrHqS-Ssj+mK=0T8QHKg34pkaw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Felipe Contreras","fromEmail":"felipe.contreras@gmail.com","sentAt":"2011-04-27T13:07:26Z","receivedAt":"2011-04-27T13:07:26Z","isPatch":false,"sender":{"key":"felipe.contreras@gmail.com","avatar":"https://avatars.githubusercontent.com/u/8358?v=4"},"body":"On Wed, Apr 27, 2011 at 3:50 PM, Jon Seymour wrote:\n> On Wednesday, April 27, 2011, Andreas Ericsson  wrote:\n>> Horrible idea. There are already as many package managers as there\n>> are packages without us throwing another one into the mix.\n>\n> I agree that there are too many package managers. But do you know\n> what? There isn't a single package manager that reliably works across\n> platform. apt-get? great. Except you need something else for Mac,\n> cywgin, or, um Fedora. Brew? Fine then you only need to worry about\n> Linux and cygwin. Cygwin? ...\n\ngem works on all of them :)\n\n-- \nFelipe Contreras\n"},{"id":"166520","messageId":"BANLkTi=UTbcijkjy5yshJynq8K3Ok-xuDw@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTikvwoCCmCofbVVPzmuA8uHxqATjTg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T13:59:56Z","receivedAt":"2011-04-27T13:59:56Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Wednesday, April 27, 2011, Felipe Contreras\n wrote:\n> On Wed, Apr 27, 2011 at 3:50 PM, Jon Seymour wrote:\n>> On Wednesday, April 27, 2011, Andreas Ericsson  wrote:\n>>> Horrible idea. There are already as many package managers as there\n>>> are packages without us throwing another one into the mix.\n>>\n>> I agree that there are too many package managers. But do you know\n>> what? There isn't a single package manager that reliably works across\n>> platform. apt-get? great. Except you need something else for Mac,\n>> cywgin, or, um Fedora. Brew? Fine then you only need to worry about\n>> Linux and cygwin. Cygwin? ...\n>\n> gem works on all of them :)\n>\n\nAh. but you have just made things harder for yourself.\n\nAssuming you use two words to install ruby, one as a command\nseparator, you need to deploy gitwork with just one word.\n\nThat said, I have heard that ruby is a _very_ concise language :-)\n\njon.\n"},{"id":"166521","messageId":"4DB82D90.6060200@op5.se","threadId":"27196","inReplyTo":"BANLkTimUHrHqS-Ssj+mK=0T8QHKg34pkaw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-04-27T14:52:00Z","receivedAt":"2011-04-27T14:52:00Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 04/27/2011 02:50 PM, Jon Seymour wrote:\n> On Wednesday, April 27, 2011, Andreas Ericsson wrote:\n>> On 04/27/2011 05:36 AM, Jon Seymour wrote:\n>>> Has anyone ever given consideration to git supporting a plugin\n>>> architecture for git extensions?\n>>>\n>>> The idea would be to provide a consistent way to install, and address\n>>> extensions to the core git functionality in a manner that does not\n>>> require the extension to actually be integrated into the git core.\n>>>\n>>\n> \n>> Horrible idea. There are already as many package managers as there\n>> are packages without us throwing another one into the mix.\n>>\n> \n> I agree that there are too many package managers. But do you know\n> what? There isn't a single package manager that reliably works across\n> platform. apt-get? great. Except you need something else for Mac,\n> cywgin, or, um Fedora. Brew? Fine then you only need to worry about\n> Linux and cygwin. Cygwin? ...\n> \n> The platform for my extension is git. Not Mac. Not Debian. Not Fedora.\n> Not cygwin. git.\n> \n> The lowest common denominator across these environments is, um, git.\n> \n\nYou're utterly horribly wrong. It'll work well enough for scripted\nlanguages but when you start mixing in compiler requirements and\nwhatnot the scheme falls apart. Quickly. Binary packages are popular\nfor (very good) reasons: They are simple, fast and there's a\nreasonable chance they've been tested fairly well with the rest of\nthe system so nothing breaks horribly once you install it.\n\nPerl, Ruby, Python and PHP all have their own extension installers.\nThat makes perfect sense since the same code runs unchanged on all\nplatforms (with some few exceptions).\n\n> I challenge the sceptIcs to specify a one line command script that\n> works across all possible environment that is more succinct than:\n> \n> git pm install gitwork\n> \n\nThat's not the point. Mac users supposedly already know about brew.\nFedora users already know about yum. Cygwin users... well, I have\nno idea what they know about, but whatever it is, it's fairly safe\nto assume they already know about it. That means they'll turn to\nthat familiar tool for managing packages when they want to install\nsomething new. What you're proposing would force users on *all*\nsystems to have to learn a new one.\n\n> It shouldn't be too hard. A tar command here, an enviroment variable\n> edit there. Perhaps a curl command or a browser download.\n> \n\nAnd what you get in the end is a f*cking mess of spaghetti shell\ncode that works worse than the existing package managers.\n\nAnd you're right. It's not too hard, so long as every extension\nmanager maintains some short list of requirements in the proper\nformat, which current package maintainers will have to learn if\nthey want some modules to be part of the \"default\" system install,\nthe way a whole bunch of Perl modules are.\n\n> You have 4 words. Knock yourself out.\n> \n\nmake install\n\nMade it in 2. What you described is what the user does to get\nnew extensions. What I described below is what developers have\nto do to make their extensions easy to install *without* a\npackage manager even if the distro the user is on doesn't ship\nthat particular extension.\n\n> \n>>> So, perhaps it won't be included in git. That's fine, I can build my\n>>> own fork of git which includes the proposed extension [ indeed, this\n>>> is how I originally developed it]. That's fine for\n>>> me, but it isn't the most practical way to distribute it to others\n>>> since I'll have to produce distribution packages for a variety of\n>>> different distribution formats or fallback to tars and zips.\n>>>\n>>\n>> What you can do is let your Makefile (or some other install-script)\n>> take the destination path for \"make install\" (or equivalent) from\n>> the output of \"git --exec-path\".\n>>\n>> That way, you can ship \"git extadd\" or whatever you want to call it\n>> as a simple installer that installs executable and man-page in their\n>> proper locations. If the commands you install require configuration\n>> by default I'd say they're broken to begin with, but even that can\n>> be remedied by running \"git config --add key value\" from the installer.\n>>\n>> So in a way, git is already its own pkg-config binary and anyone\n>> clever enough to write useful scripts that enhances git will almost\n>> certainly see that and use it from their favourite language quite\n>> without having to learn some new magic format for package management.\n>>\n> \n> Those 3 paragraphs were substantially longer than 4 words. Again,\n> there is a tar ball, let me know how I can install it across alll\n> environments that got runs on. Make sure the man pages work.\n> \n\nSo the complete description would be\n\n git clone git://somerepo/gitworks\n cd gitworks\n make install\n\nand the rest is in developer hands. If you make the extension\nmanager run *ONLY* those commands, you've made it fairly simple for\nextension developers and users both, but then the gain is so\nextremely small that it's hardly worth it anymore, although I agree\nit would be nifty to keep a list of popular extensions on a wiki\nsomewhere so users can actually find them.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"166523","messageId":"BANLkTi=XcR9FTPC8oe100fMneNf1nca4_Q@mail.gmail.com","threadId":"27196","inReplyTo":"4DB82D90.6060200@op5.se","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T15:36:15Z","receivedAt":"2011-04-27T15:36:15Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 12:52 AM, Andreas Ericsson wrote:\n> On 04/27/2011 02:50 PM, Jon Seymour wrote:\n>> On Wednesday, April 27, 2011, Andreas Ericsson  wrote:\n>>> On 04/27/2011 05:36 AM, Jon Seymour wrote:\n>>>> Has anyone ever given consideration to git supporting a plugin\n>>>> architecture for git extensions?\n>>>>\n>>>> The idea would be to provide a consistent way to install, and address\n>>>> extensions to the core git functionality in a manner that does not\n>>>> require the extension to actually be integrated into the git core.\n>>>>\n>>>\n>>\n>>> Horrible idea. There are already as many package managers as there\n>>> are packages without us throwing another one into the mix.\n>>>\n>>\n>> I agree that there are too many package managers. But do you know\n>> what? There isn't a single package manager that reliably works across\n>> platform. apt-get? great. Except you need something else for Mac,\n>> cywgin, or, um Fedora. Brew? Fine then you only need to worry about\n>> Linux and cygwin. Cygwin? ...\n>>\n>> The platform for my extension is git. Not Mac. Not Debian. Not Fedora.\n>> Not cygwin. git.\n>>\n>> The lowest common denominator across these environments is, um, git.\n>>\n>\n> You're utterly horribly wrong. It'll work well enough for scripted\n> languages but when you start mixing in compiler requirements and\n> whatnot the scheme falls apart. Quickly. Binary packages are popular\n> for (very good) reasons: They are simple, fast and there's a\n> reasonable chance they've been tested fairly well with the rest of\n> the system so nothing breaks horribly once you install it.\n> Perl, Ruby, Python and PHP all have their own extension installers.\n> That makes perfect sense since the same code runs unchanged on all\n> platforms (with some few exceptions).\n>\n\nYeah, but that's when you delegate to a OS-specific package manager.\n\nConcens. Separated. Good principle, that.\n\n>> I challenge the sceptIcs to specify a one line command script that\n>> works across all possible environment that is more succinct than:\n>>\n>>     git pm install gitwork\n>>\n>\n> That's not the point. Mac users supposedly already know about brew.\n> Fedora users already know about yum. Cygwin users... well, I have\n> no idea what they know about, but whatever it is, it's fairly safe\n> to assume they already know about it. That means they'll turn to\n> that familiar tool for managing packages when they want to install\n> something new. What you're proposing would force users on *all*\n> systems to have to learn a new one.\n>\n>> It shouldn't be too hard. A tar command here, an enviroment  variable\n>> edit there. Perhaps a curl command or a browser download.\n>>\n>\n> And what you get in the end is a f*cking mess of spaghetti shell\n> code that works worse than the existing package managers.\n>\n\nI guess that really depends on who you ask to write the shell script.\n\nMost package managers have fairly straight forward interfaces.\n\n brew install blah\n apt-get install blah\n git clone git://github.com/blah/blah\n\nThere is no reason why some with a modicum of shell scripting nous\ncould not whip together\na simple meta interface for platform-specific package managers that\nknows how to:\n\n* read a specification from a git config file\n* apply that specification to the task of invoking a platform specific\npackage manager.\n\nSome one really smart could probably do it in an extensible way that\ncoped with the concept that different OS-platforms have different\npackage managers.\n\nMost of this pasta can be cooked once, by the person who writes\ngpm/git-pm. Sauce would be extra, of course.\n\n> And you're right. It's not too hard, so long as every extension\n> manager maintains some short list of requirements in the proper\n> format, which current package maintainers will have to learn if\n> they want some modules to be part of the \"default\" system install,\n> the way a whole bunch of Perl modules are.\n>\n>> You have 4 words. Knock yourself out.\n>>\n>\n> make install\n\n>\n> Made it in 2. What you described is what the user does to get\n> new extensions. What I described below is what developers have\n> to do to make their extensions easy to install *without* a\n> package manager even if the distro the user is on doesn't ship\n> that particular extension.\n>\n\nAgain, there is a package called gitwork, available. It is available\nas a tarball. Somewhere.\nInstall it.\n\n* look up the url (google, might help)\n* dowload it with your favourite download tool (browser, curl)\n* unpack it\n* install its dependencies, if required\n* configure it\n* buiild it\n\nYour two words only specified the very last step. I needed 6 bullet\npoints merely to explain the details you omitted.\n\n>\n> So the complete description would be\n>\n>  git clone git://somerepo/gitworks\n>  cd gitworks\n>  make install\n\nStill more than 4 words.\n\njon.\n"},{"id":"166524","messageId":"BANLkTikGZgEb-4jzHt+t2k__s7BMgbU9gg@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTi=XcR9FTPC8oe100fMneNf1nca4_Q@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T16:13:56Z","receivedAt":"2011-04-27T16:13:56Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"I think my use of the word package was unfortunate, since it suggests\nI am proposing an alternative to tools such as apt-get, brew, rpm etc.\n\nThis is not the intention. The intention is to manage _plugins_ to\ngit, treating git itself as a platform.\n\nPlugins will be delivered via platform-specific package managers\n(perhaps sequenced by git-pm), but once they arrive on the OS platform\nthey will be _activated_ by the plugin manager and this made available\nto the git command line.\n\nPlatform specific concerns such as building and (most) dependency\nmanagement will be delegated to platform specific package managers.\n\nThe overriding objective is to allow a git user to install a git\nplugin called foobar with 4 words:\n\n git pm install foobar\n\ngiven that someone, somwhere, has done the work to create a plugin\ndescriptor and create an installable package of some kind for whatever\npackage managers are required in order to successfully install the\nplugin on the target platform.\n\nThe same command should work whether your git platform is hosted on\nMAC OSX, cygwin, Debian, Fedora, AIX or Windows.\n\nWhere git can be used as the underlying package manager, it will be\n(for extensions which really are just source repos). If more\nsophisticated build support is required, then that will be delegated\nto a platform specific package manager via one of a small number of\npackage manager adapters.\n\nHere is an updated README that hopefully makes this clear.\n\n[ An easier to read version is here - https://github.com/jonseymour/gpm ]\n\n--------------------\n\nNAME\n====\ngit-pm - a plugin manager for git extensions\n\nDESCRIPTION\n===========\nThe initial deliverable of the project will be a plugin architecture\nproposal. The intent of this deliverable is to create specifications\nthat will allow plugin authors to create descriptors for their plugins\nthat will be sufficient to enable git-pm to locate an appropriate\npackage manager and delegate installation of the plugin to that package manager.\n\nIn parallel to this deliverable, a plugin manager interface (git-pm)\nwill be developed. Such an interface will manage git plugins on\nbehalf of git by delegating to whatever package-managers are available\nand installed on the platform.\n\nPRINCIPLES\n==========\n* define a repository layout specification\n* define a plugin descriptor (using the git config syntax)\n* package manager agnostic repo and plugin specifications\n * perhaps define a pluggable plugin manager interface\n* support for:\n * existing contrib/ directory\n * existing git patterns for finding and using extensions\n * man pages\n * plugin specific configuration help\n * bash completions\n * scripts\n* build support:\n * for documentation, archives\n* layers\n * repo, plugin descriptors\n * tool interface specifications\n * tool implementations\n * global plugin registry and repository\n\nINTENDED SCENARIOS\n==================\n\nInstallation and Removal\n------------------------\nThere is completely understandable resistance to YAPM - yet another\npackage manager. This is not the goal of git-pm. In particular, git-pm\nwill delegate platform-specific build\nand deployment concerns to platform-specific package managers such as\napt-get, rpm, brew and cygwin. That said, there is no good reason why\ngit-pm shouldn't know how to delegate such concerns to a\nplatform-specific package manager.\n\nThe basic intent is to allow plugin authors to provide simple\ninstructions to potential consumers of their plugin.\n\n
\nInstalling a plugin should be as simple as:\n\n\t git pm install foobar\n\nSuch a comamnd should work whether the platform is Linux, cygwin or\nMac OSX. In fact, the only\ncommon denominator should be git itself, and its dependencies (POSIX\nshell and perl).\n
\nInstall a plugin, given a URL that can locate its descriptor:\n\n\t git pm install [ plugin-url | plugin-archive | plugin-name ]\n\n
\nRemove a plugin, given a name that can identify it:\n\n\t git pm remove plugin-name\n\n
\nUpdate an installed plugin:\n\n\t git pm update plugin-name\n\n
\nInspect a registry of available available, installed, active or\ninactive plugins:\n\n\t git pm list available|installed|active|inactive\n\n
\nDescribe the current installation, availability or activation status\nof a plugin:\n\n\t git pm status plugin-name\n\n
\n\nActivation/De-activation\n------------------------\nActivation is the means by which a locally available plugin can be\nmade available to the git command line. The idea is to\n\n\t git-pm activate plugin-name\n\t git-pm deactivate plugin-name\n\nWHAT GIT-PM IS:\n===============\n* a native extension manager for the git platform\n* an _activator_ for git extensions\n* distribution and platform package mamager friendly\n* git-aware\n\nWHAT GIT-PM IS NOT:\n===================\n* a build tool\n* a replacement for a package manager\n* useful for anything other than git extensions\n\nCONCEPTS\n========\n\nplugin\n------\nAn extension to git that exports 1 or more commands to the git command line\n\npackage\n-------\nA platform-specific archive that is installable by a platform-specific\npackage manager. Packages will _package_ plugins.\n\nplugin-descriptor\n-----------------\nA package-manager agnostic descriptor that describes a plugin to the\ngit platform, in particular git-pm.\n\npackage-descriptor\n------------------\nA package-manager specific descriptor that describes a package to a\npackage manager.\n\nplugin manager\n--------------\nA command, such as git-pm, that can install, remove, activate or\ndeactive plugins by delegating platform specific\nconcerns to a platform-specific package manager.\n\npackage-manager\n---------------\nA platform-specific manager of packages.\n\nplugin author\n-------------\nAn author of git plugins.\n\npackage author\n--------------\nAn author of package specifications for a package manager. In\nparticular, the author of a package specification that allows\na git plugin to be bundled into a package for the purposes of\ndistribution and management.\n\npackage-manager-adapter\n-----------------------\nA pluggable component of git-pm that exposes a platform-specific\npackage manager via a uniform interface.\n\nDEPENDENCY MANAGEMENT\n=====================\nIt is unclear yet how important dependency management will be. Where\npossible, such concerns will be delegated to\nplatform-specific package managers. That said, there may still be\nvalue in managing dependencies between git-pm\npackages at the git-pm level.\n\nPACKAGE NAME\n============\nThe package name is currently gpm. Howeve, the \"General Purpose Mouse\"\npackage has already claimed this name in the apt space, at least.\n\nSo, it might be better to use 'git-pm' as the package name, which\nisn't so bad since idiomatic use of the package should be 'git pm\nblah'.\n\nSUPPORTED PACKAGE MANGERS\n=========================\nThe intent of git-pm is not to duplicate the functionality of existing\npackage managers. The intent is to provide a package manager for git\nas a platform itself. To the extent that a build process is required\nto install a git extension, then such concerns will be delegated\nto a real package manager that knows how to deal with such concerns.\n\nThe intent is that a minimal plugin that depends only on the\navailability of a shell, should be installable with something as\nsimple as:\n\n git pm install foobar\n\nThis should work whether your git install is running on Linux, cywgin,\nWindows (MSYSGIT), MAC, AIX or whatever.\n\nIf a compilation is required, then delegation to a platform package\nmanager will be requried.\n\nLinux\n-----\n* git\n* rpm\n* apt\n\nMac\n---\n* git\n* brew\n\ncygwin\n---\n* git\n\nCONTRACTS\n=========\nThe following contracts will be required between:\n\n
\n
the git user and git-pm
\n
\nThis contract will be specified in terms of the git-pm man page. It\nwill specify the plugin management commands offered by\nthe git-pm interface to the user.\n
\n
the git runtime and git-pm
\n
\nThis contract will specify the technique by which git-pm exposes git\nextensions to the git command line. It will include\nsupport for exposing:\n
    \n
  • sub-commands
    • \n
  • man pages
    • \n
  • shell completions
    • \n
\n
\n
git-pm and package-manager adapters
\n
\nThis contract will specify how to add a new package-manager adapter.\nThe purpose will be to allow git-pm to delegate\nits interface to backend package managers that know how to manage\nplatform specific concerns such as building,\ndependency management, package distribution etc.\n
\n\n
package-manager adapters and package managers
\n
extension authors and the git-pm package manager
\n
\n\nINFLUENCES\n==========\nThe following programs have influenced the design of git-pm.\n\nnpm\n---\nThe node package manager.\n\nNode is an interesting, V8-JavaScript based runtime for implementing\nservers. Node comes with a tightly coupled package manager npm. If\nnode is your platform, npm\nis the package manager for that platform. In particular, npm works the\nsame way irrespective of which platform you have node installed on.\n\nbrew\n----\nA Mac OSX specific package manager.\n\nBrew is a relatively new package manager for the Mac OSX operating\nsystem. It has several nice features, including its formula registry\nthat allows\nauthors to specify succinct package management formulae as short ruby\nscripts. Brew also uses git as an integral part of its registry and\nrun-time.\n\nSCEPTICS CHALLENGE\n==================\nSome people doubt there is value in a 'git plugin mamager'. In\nresponse to this scepticism, I pose the following\nchallenge.\n\n1. take an arbitrary git extension.\n2. specify installation instructions for that extension in 4 words or less.\n3. make sure those 4 words work on Linux, Cygwin, MAC OSX and AIX.\n4. verify that following installation, the man pages work.\n\nAs an example, there is a package called gitwork. It is available\nsomewhere on the Internet. I think, as a tarball. Or perhaps a zip. I\ndon't think it has any dependencies, but I am really not sure. Why\ndon't you suck it and see?\n\nMAILING LIST\n============\nUntil noted otherwise, please use the\n[http://dir.gmane.org/gmane.comp.version-control.git](git@vger.kernel.org)\nmailing list for discussions about design decisions. gpm: is suggested\na good prefix for such discussions.\n\nREVISIONS\n=========\nOrdered most recent, to less recent:\n\n* changed 'gpm' to 'git pm' on the assumption that 'git-pm' will be in\nthe path and that 'General Purpose Mouse' has already nabbed 'gpm'\n* changed terminology from 'package' to 'plugin' to help reduce\nconsfusion about the objectives of the project\n\nAUTHOR\n======\nJon Seymour\n"},{"id":"166528","messageId":"4DB84D65.6070906@gmail.com","threadId":"27196","inReplyTo":"BANLkTikGZgEb-4jzHt+t2k__s7BMgbU9gg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2011-04-27T17:07:49Z","receivedAt":"2011-04-27T17:07:49Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"On 04/27/2011 12:13 PM, Jon Seymour wrote:\n> I think my use of the word package was unfortunate, since it suggests\n> I am proposing an alternative to tools such as apt-get, brew, rpm etc.\n>\n> This is not the intention. The intention is to manage _plugins_ to\n> git, treating git itself as a platform.\n>\n> Plugins will be delivered via platform-specific package managers\n> (perhaps sequenced by git-pm), but once they arrive on the OS platform\n> they will be _activated_ by the plugin manager and this made available\n> to the git command line.\n>\n> Platform specific concerns such as building and (most) dependency\n> management will be delegated to platform specific package managers.\n>\n> The overriding objective is to allow a git user to install a git\n> plugin called foobar with 4 words:\n>\n> git pm install foobar\n>\n> given that someone, somwhere, has done the work to create a plugin\n> descriptor and create an installable package of some kind for whatever\n> package managers are required in order to successfully install the\n> plugin on the target platform.\n>\n> The same command should work whether your git platform is hosted on\n> MAC OSX, cygwin, Debian, Fedora, AIX or Windows.\n>\n> Where git can be used as the underlying package manager, it will be\n> (for extensions which really are just source repos). If more\n> sophisticated build support is required, then that will be delegated\n> to a platform specific package manager via one of a small number of\n> package manager adapters.\n\nFor a git plugin ecosystem to work, a (relatively) stable API/ABI is \nnecessary for the plugin authors to code to. Where is your proposal for \nthat.\n"},{"id":"166535","messageId":"7vbozr8uo8.fsf@alter.siamese.dyndns.org","threadId":"27196","inReplyTo":"4DB82D90.6060200@op5.se","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-27T17:34:47Z","receivedAt":"2011-04-27T17:34:47Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson writes:\n\n> You're utterly horribly wrong. ...\n> ...\n> So the complete description would be\n>\n> git clone git://somerepo/gitworks\n> cd gitworks\n> make install\n>\n> and the rest is in developer hands.\n\nYeah, I like this as the conclusion of this thread ;-).\n"},{"id":"166540","messageId":"7vpqo77dlr.fsf@alter.siamese.dyndns.org","threadId":"27196","inReplyTo":"7vbozr8uo8.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-27T18:28:48Z","receivedAt":"2011-04-27T18:28:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Andreas Ericsson writes:\n>\n>> You're utterly horribly wrong. ...\n>> ...\n>> So the complete description would be\n>>\n>> git clone git://somerepo/gitworks\n>> cd gitworks\n>> make install\n>>\n>> and the rest is in developer hands.\n>\n> Yeah, I like this as the conclusion of this thread ;-).\n\nHaving said that, to make this work well not just for the command but for\ndocumentation and help, there needs a way for the build procedure of such\nuser-script project to query the manpage and the documentation paths, just\nlike we let them query the executable path via \"git --exec-path\".\n"},{"id":"166542","messageId":"1303930175.25134.38.camel@drew-northup.unet.maine.edu","threadId":"27196","inReplyTo":"7vpqo77dlr.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-04-27T18:49:35Z","receivedAt":"2011-04-27T18:49:35Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Wed, 2011-04-27 at 11:28 -0700, Junio C Hamano wrote:\n> Junio C Hamano writes:\n> \n> > Andreas Ericsson writes:\n> >\n> >> You're utterly horribly wrong. ...\n> >> ...\n> >> So the complete description would be\n> >>\n> >> git clone git://somerepo/gitworks\n> >> cd gitworks\n> >> make install\n> >>\n> >> and the rest is in developer hands.\n> >\n> > Yeah, I like this as the conclusion of this thread ;-).\n> \n> Having said that, to make this work well not just for the command but for\n> documentation and help, there needs a way for the build procedure of such\n> user-script project to query the manpage and the documentation paths, just\n> like we let them query the executable path via \"git --exec-path\".\n\nI was just thinking of that, and for hoots and hollers I\ncopied /usr/share/man/man1/git-am.1.gz\nto /usr/share/man/man1/git-amp.1.gz and tried \"git help amp\" on it.\n\n\t[dnorthup@drew-northup ~]$ git help amp\n\tNo manual entry for gitamp\n\nSo, that doesn't work. I haven't checked yet how Git \"knows\" what valid\npages are available for \"git help\" but just putting another file in the\nsame directory as the others didn't do the job (at least not on my\nworkstation).\n\nHowever, as noted earlier, copying /usr/bin/git-am to /usr/bin/git-amp\ndid work. Executing \"git amp -h\" resulted in the built-in help text for\n'git am' being printed to the screen, exactly as expected.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"166544","messageId":"20110427191612.GB2667@jakstys.lt","threadId":"27196","inReplyTo":"BANLkTikGZgEb-4jzHt+t2k__s7BMgbU9gg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Motiejus Jakštys","fromEmail":"desired.mta@gmail.com","sentAt":"2011-04-27T19:16:12Z","receivedAt":"2011-04-27T19:16:12Z","isPatch":false,"sender":{"key":"desired.mta@gmail.com","avatar":"https://gravatar.com/avatar/5d7d88e7b672acebe3472e92baccb5f933fbd282b6131e22e32d96e5818b5b38?d=mp&s=160"},"body":"On Thu, Apr 28, 2011 at 02:13:56AM +1000, Jon Seymour wrote:\n> Platform specific concerns such as building and (most) dependency\n> management will be delegated to platform specific package managers.\n> \n> The overriding objective is to allow a git user to install a git\n> plugin called foobar with 4 words:\n> \n> git pm install foobar\n> \n> given that someone, somwhere, has done the work to create a plugin\n> descriptor and create an installable package of some kind for whatever\n> package managers are required in order to successfully install the\n> plugin on the target platform.\n> \n> The same command should work whether your git platform is hosted on\n> MAC OSX, cygwin, Debian, Fedora, AIX or Windows.\n> \n> Where git can be used as the underlying package manager, it will be\n> (for extensions which really are just source repos). If more\n> sophisticated build support is required, then that will be delegated\n> to a platform specific package manager via one of a small number of\n> package manager adapters.\n\nOk, I write my \"git logx\", which is a single file -- git-logx.c.\nCompilation steps:\n $ gcc -lz git-logx.c. \n\n> then that will be delegated to a platform specific package manager \n\nWhich one? Say I am on debian. dpkg-buildpackage? So I would get a\ngit-logx.deb, which I should install as root? In that case, you forgot\none word:\n\n sudo git pm install foobar\n\nOr I got it wrong?\n\nMotiejus\n"},{"id":"166545","messageId":"20110427191933.GC2667@jakstys.lt","threadId":"27196","inReplyTo":"20110427191612.GB2667@jakstys.lt","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Motiejus Jakštys","fromEmail":"desired.mta@gmail.com","sentAt":"2011-04-27T19:19:34Z","receivedAt":"2011-04-27T19:19:34Z","isPatch":false,"sender":{"key":"desired.mta@gmail.com","avatar":"https://gravatar.com/avatar/5d7d88e7b672acebe3472e92baccb5f933fbd282b6131e22e32d96e5818b5b38?d=mp&s=160"},"body":"On Wed, Apr 27, 2011 at 08:16:12PM +0100, Motiejus Jakštys wrote:\n> Which one? Say I am on debian. dpkg-buildpackage? So I would get a\n> git-logx.deb, which I should install as root? In that case, you forgot\n> one word:\n> \n> sudo git pm install foobar\n> \n> Or I got it wrong?\n\nMaybe you mean this...\n $ git pm install foobar\n $ sudo dpkg -i foobar.deb\n\nWhich does not make really happy...\n\nMotiejus\n"},{"id":"166548","messageId":"20110427194233.GA16717@gnu.kitenet.net","threadId":"27196","inReplyTo":"1303930175.25134.38.camel@drew-northup.unet.maine.edu","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Joey Hess","fromEmail":"joey@kitenet.net","sentAt":"2011-04-27T19:42:33Z","receivedAt":"2011-04-27T19:42:33Z","isPatch":false,"sender":{"key":"joey@kitenet.net","avatar":"https://avatars.githubusercontent.com/u/16392?v=4"},"body":"Drew Northup wrote:\n> I was just thinking of that, and for hoots and hollers I\n> copied /usr/share/man/man1/git-am.1.gz\n> to /usr/share/man/man1/git-amp.1.gz and tried \"git help amp\" on it.\n> \n> \t[dnorthup@drew-northup ~]$ git help amp\n> \tNo manual entry for gitamp\n> \n> So, that doesn't work. I haven't checked yet how Git \"knows\" what valid\n> pages are available for \"git help\" but just putting another file in the\n> same directory as the others didn't do the job (at least not on my\n> workstation).\n\nIf git-amp is available in $PATH, 'git help amp' runs 'man git-amp'.\nOtherwise, it runs 'man gitamp'.\n\nTools like autoconf etc already know how to install man pages into the\nright places. I don't see the need for any additional support for git\nhere.\n\n-- \nsee shy jo\n"},{"id":"166551","messageId":"1303935396.25134.79.camel@drew-northup.unet.maine.edu","threadId":"27196","inReplyTo":"20110427194233.GA16717@gnu.kitenet.net","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Drew Northup","fromEmail":"drew.northup@maine.edu","sentAt":"2011-04-27T20:16:36Z","receivedAt":"2011-04-27T20:16:36Z","isPatch":false,"sender":{"key":"drew.northup@maine.edu","avatar":"https://avatars.githubusercontent.com/u/18331571?v=4"},"body":"\nOn Wed, 2011-04-27 at 15:42 -0400, Joey Hess wrote:\n> Drew Northup wrote:\n> > I was just thinking of that, and for hoots and hollers I\n> > copied /usr/share/man/man1/git-am.1.gz\n> > to /usr/share/man/man1/git-amp.1.gz and tried \"git help amp\" on it.\n> > \n> > \t[dnorthup@drew-northup ~]$ git help amp\n> > \tNo manual entry for gitamp\n> > \n> > So, that doesn't work. I haven't checked yet how Git \"knows\" what valid\n> > pages are available for \"git help\" but just putting another file in the\n> > same directory as the others didn't do the job (at least not on my\n> > workstation).\n> \n> If git-amp is available in $PATH, 'git help amp' runs 'man git-amp'.\n> Otherwise, it runs 'man gitamp'.\n\nThat's what I thought too, but it didn't work! () I'll have to try a couple of other ways to break it later on.\n\n> Tools like autoconf etc already know how to install man pages into the\n> right places. I don't see the need for any additional support for git\n> here.\n\nI'm not saying there should be--in fact quite the opposite.\n\n-- \n-Drew Northup\n________________________________________________\n\"As opposed to vegetable or mineral error?\"\n-John Pescatore, SANS NewsBites Vol. 12 Num. 59\n"},{"id":"166559","messageId":"20110427212943.GA2646@jakstys.lt","threadId":"27196","inReplyTo":"BANLkTinh3v1o7t4HRwzZtFW--zu-j4U3kw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Motiejus Jakštys","fromEmail":"desired.mta@gmail.com","sentAt":"2011-04-27T21:29:43Z","receivedAt":"2011-04-27T21:29:43Z","isPatch":false,"sender":{"key":"desired.mta@gmail.com","avatar":"https://gravatar.com/avatar/5d7d88e7b672acebe3472e92baccb5f933fbd282b6131e22e32d96e5818b5b38?d=mp&s=160"},"body":"On Wed, Apr 27, 2011 at 01:36:44PM +1000, Jon Seymour wrote:\n> Has anyone ever given consideration to git supporting a plugin\n> architecture for git extensions?\n> \n\nHow about this proposition? From the user perspective:\n$ cd /somewhere/might/be/home/or/project/.git/ext/\n$ git clone git://github.com/jonseymour/gitwork.git\n\nWhat user finds in gitwork/ is totally up to maintainer. git cares about\ntwo files:\n .git/ext/git-work(.exe)\n .git/ext/git-work.1.gz\n\n$ cd gitwork;\n$ (c)make|./waf|scons|what_the_hell_just_produce_git-work\n$ git config ext.work.enabled true\n\nWhat git does when git is invoked:\n-------------------------------------------\n* config.ext..enabled is true. If not, do nothing new.\n* if above is true, search for git-work in:\n ** project directory\n ** user home directory\n* if found, execute it\n* if not found, fallback to default mechanism (check in\n cmd_struct_commands, etc)\n\nSimilar with man pages.\n\nThink about how Vim plugins are distributed. Vim developers assumed that\nusers are educated enough to download the plugin and extract it to the\nright place. Are git users less intelligent to download & install it,\nespecially in a case when they need an *extension*?\n\nAre you trying to kill a bird with a rock?\n\nMotiejus\n"},{"id":"166561","messageId":"7vwrif5q93.fsf@alter.siamese.dyndns.org","threadId":"27196","inReplyTo":"20110427194233.GA16717@gnu.kitenet.net","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-27T21:38:32Z","receivedAt":"2011-04-27T21:38:32Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Joey Hess writes:\n\n> Tools like autoconf etc already know how to install man pages into the\n> right places. I don't see the need for any additional support for git\n> here.\n\nBut the original point by Andreas was that third-party tools like \"git\nwork\" should be able to just say \"make install\", and of course the distro\npeople can take it from there, but the thing is, distro people can take it\nfrom a very low starting point. Unless \"make install\" does not figuire\nout how the user's git is configured and installed, it won't be very\nuseful for end users who do say \"make install\" for whatever reason,\ninstead of installing it from their distro.\n\nFor example, on my primary development box, I do not have any git\ninstalled from distribution, but I do have git on my $PATH. For such\nusers, \"make install\" should be able to find out that the right place to\ninstall git-work.1 is in $HOME/some/where/man/man1 directory.\n"},{"id":"166562","messageId":"BANLkTi=H3oU5SxwJJZ9ZYJBWy+VS2CvJ7w@mail.gmail.com","threadId":"27196","inReplyTo":"20110427212943.GA2646@jakstys.lt","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T21:47:25Z","receivedAt":"2011-04-27T21:47:25Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"2011/4/28 Motiejus Jakštys :\n- Hide quoted text -\n> On Wed, Apr 27, 2011 at 01:36:44PM +1000, Jon Seymour wrote:\n>> Has anyone ever given consideration to git supporting a plugin\n>> architecture for git extensions?\n>>\n>\n> How about this proposition? From the user perspective:\n> $ cd /somewhere/might/be/home/or/project/.git/ext/\n> $ git clone git://github.com/jonseymour/gitwork.git\n>\n> What user finds in gitwork/ is totally up to maintainer. git cares about\n> two files:\n> .git/ext/git-work(.exe)\n> .git/ext/git-work.1.gz\n>\n> $ cd gitwork;\n> $ (c)make|./waf|scons|what_the_hell_just_produce_git-work\n> $ git config ext.work.enabled true\n>\n> What git does when git is invoked:\n> -------------------------------------------\n> * config.ext..enabled is true. If not, do nothing new.\n> * if above is true, search for git-work in:\n> ** project directory\n> ** user home directory\n> * if found, execute it\n> * if not found, fallback to default mechanism (check in\n> cmd_struct_commands, etc)\n>\n> Similar with man pages.\n>\n> Think about how Vim plugins are distributed. Vim developers assumed that\n> users are educated enough to download the plugin and extract it to the\n> right place. Are git users less intelligent to download & install it,\n> especially in a case when they need an *extension*?\n>\n> Are you trying to kill a bird with a rock?\n>\n> Motiejus\n>\n\nI think that is a little more invasive of git-core than it needs to be.\n\nI was thinking more along the lines of, having solved the distribution\nand build problem _some other way_, resulting in a foobar.gpm file\nending up in, say, /usr/local/lib/git-pm/foobar.gpm.\n\nYou would then run:\n\n git pm activate foobar\n\nwhich would then link:\n\n ln -sf /usr/local/bin/git-foobar ~/.git-pm/activated/libexec/git-foobar\n ln -sf /usr/local/share/man/man1 ~/.git-pm/activated/share/man/man1\n\nOne would have to have previously arranged for the sub directories of\n~/git-pm/activated to be in the PATH and MANPATH paths.\n\nDeactivating would involve removing the links.\n\nDeciding which links to link during activation and de-activation would\nbe driven by a short descriptor file.\n\njon.\n"},{"id":"166563","messageId":"20110427220748.GA19578@elie","threadId":"27196","inReplyTo":"7vwrif5q93.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-27T22:08:27Z","receivedAt":"2011-04-27T22:08:27Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> For example, on my primary development box, I do not have any git\n> installed from distribution, but I do have git on my $PATH. For such\n> users, \"make install\" should be able to find out that the right place to\n> install git-work.1 is in $HOME/some/where/man/man1 directory.\n\nSorry to be dense, but: isn't the right place to install git-work.1\none of\n\n\t/usr/local/share/man\n\t/usr/share/man\n\t/opt/man\n\t$HOME/man\n\t$prefix/man\n\ndepending on where the git-work binary was installed? In the $prefix\ncase, the same snippet in .profile that adds $prefix/bin to the $PATH\nwould also say\n\n\tMANPATH=$prefix/man:$(manpath)\n\nOr is the idea to blindly install (a symlink to) git-work to $(git\n--exec-path)/ rather than a place on the $PATH? In this case, I would\nbe a little worried. How will the helper deal with uninstallation and\nwith namespace conflicts? (On the $PATH, these are expected problems\nand I'd expect each user has some way of dealing with them already.)\n"},{"id":"166565","messageId":"BANLkTikSsoCP_d34wdBHX=r336zJSHSWEQ@mail.gmail.com","threadId":"27196","inReplyTo":"20110427220748.GA19578@elie","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T22:32:48Z","receivedAt":"2011-04-27T22:32:48Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 8:08 AM, Jonathan Nieder wrote:\n> Junio C Hamano wrote:\n\n> Or is the idea to blindly install (a symlink to) git-work to $(git\n> --exec-path)/ rather than a place on the $PATH?  In this case, I would\n> be a little worried.  How will the helper deal with uninstallation and\n> with namespace conflicts?  (On the $PATH, these are expected problems\n> and I'd expect each user has some way of dealing with them already.)\n\nI see 'git pm activate' managing symbolic links in a directory\ndedicated to the purpose (.e.g. ~/.git-pm/activated).\n\nOne thing 'git pm activate' could do is check that the commands\nexported by the 'gitwork' descriptor do not conflict with what is\nalready activated.\n\nIf the user has done something like:\n\n git clone https://repo/gitwork.git ~/hub/gitwork\n\nand then:\n\n git activate pm ~/hub/gitwork\n\nthe symbolic links would be established to ~/hub/gitwork, wherever\nthat happens to be.\n\nIf the user has done:\n\n apt-get install gitwork\n\nthen given a package-manager adapter for apt-get, it could extract the\n.gpm file from the list of installed files, and resume activation from\nthere. Ultimately, the end result is the same ~/.git-pm/activated is\nupdated, it has always been on the paths it needs to be.\n\nIf the descriptor did have a list of exported commands (e.g. git-work,\ngit-base, git-atomic, git-test), then a global registry could use this\nlist of exported commands to detect conflicts early - at package\nregistration time which might help avoid grief down the track.\n"},{"id":"166566","messageId":"BANLkTimsWmtXzogjN4bPkhmV8K=y1c4AmA@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTinRUaGmF5xqmVGWFurGMtO8Cgb9Hg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Pau Garcia i Quiles","fromEmail":"pgquiles@elpauer.org","sentAt":"2011-04-27T22:32:58Z","receivedAt":"2011-04-27T22:32:58Z","isPatch":false,"sender":{"key":"pgquiles@elpauer.org","avatar":null},"body":"Hi,\n\nCan we please split this debate into the two threads that have arisen?\n\na) git extensions (the original point)\n\nb) git package manager\n\n\nLet me give my unrequested opinion:\n\na) I like it. Mercurial has it. It requires more or less what Jon says\nbelow: let's define a hierarchy of where to place the executables,\ndocumentation, the extenions' porcelain (which IMHO would require one\ndirectory per extension), etc\n\nb) Please no. As a Debian developer, I'd rather see extensions\ndistributed as source, then I would package them. It's what Debian\n(and other distributions) are doing now with Ruby gems, Python eggs,\netc: we provide packages for them so that you do not use gem, etc\n\n\n\n\n\nOn Wed, Apr 27, 2011 at 7:33 AM, Jon Seymour wrote:\n> Hide quoted text -\n> On Wed, Apr 27, 2011 at 3:17 PM, Junio C Hamano wrote:\n>> Jon Seymour writes:\n>>\n>>>> So if you have /home/js/bin on your $PATH, you can install your \"git-work\"\n>>>> script as /home/js/bin/git-work, and that should be sufficient.\n>>>\n>>> Yep, that's a start, but does not a a complete plugin architecture make :-)\n>>\n>> Please explain yourself.\n>>\n>\n> So, I think at a very minimum, a plugin architecture should specify\n> the file system layout of packages to be managed by a plugin/package\n> manager.\n>\n> So, where to find scripts, where to find man pages, bash completions,\n> configuration help etc.\n>\n> A slightly more functional architecture would provide support for\n> unpacking package archives into a \"standard\" repository location and\n> for removing unwanted plugins.\n>\n> A plugin architecture might specify a standard way to access\n> extensions. (git blah is easy for local use, but what if a plugin\n> grabs a \"noun\" that the core wants to use that \"noun\" itself in\n> future. Perhaps gitx blah would be a better standard way to access\n> extensions. But that is an aside, I am sure this question has been\n> considered previously).\n>\n> An even more functional architecture would provide support for a\n> global registry of plugins. I understand that git may not want to\n> write its own package manager (how many times has that been done),\n> but it'd be nice if competing \"git package managers\" had a standard\n> target to deploy to.\n>\n> My thoughts about this are inspired by how the node project manages\n> packages with its npm package manager and also the fact that I have\n> several ideas on the boil at the moment that would definitely benefit\n> from a standard way to manage these concerns.\n>\n> jon.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at  http://vger.kernel.org/majordomo-info.html\n>\n\n\n\n-- \nPau Garcia i Quiles\nhttp://www.elpauer.org\n(Due to my workload, I may need 10 days to answer)\n"},{"id":"166567","messageId":"BANLkTinxFNSXEnRR0ZACO0W-+kDL0CD-qg@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTimsWmtXzogjN4bPkhmV8K=y1c4AmA@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-27T22:47:48Z","receivedAt":"2011-04-27T22:47:48Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 8:32 AM, Pau Garcia i Quiles\n wrote:\n> Hi,\n>\n> Can we please split this debate into the two threads that have arisen?\n>\n> a) git extensions (the original point)\n>\n> b) git package manager\n>\n>\n> Let me give my unrequested opinion:\n>\n> a) I like it. Mercurial has it. It requires more or less what Jon says\n> below: let's define a hierarchy of where to place the executables,\n> documentation, the extenions' porcelain (which IMHO would require one\n> directory per extension), etc\n>\n\n\n> b) Please no. As a Debian developer, I'd rather see extensions\n> distributed as source, then I would package them. It's what Debian\n> (and other distributions) are doing now with Ruby gems, Python eggs,\n> etc: we provide packages for them so that you do not use gem, etc\n>\n\nI absolutely agree that is the right approach. To the extent that my\nproposal supports:\n\n git pm install foobar\n\nit would do so by delegation to package-manager adapters (in effect\nacting as a meta package manager).\n\nHowever, I don't want to further distract discussion by having a\ndebate about whether a meta package\nmanager is a good idea or not. So let's concentrate on what:\n\n git pm activate\n\nwould look like and do.\n\njon.\n"},{"id":"166573","messageId":"7vsjt35l84.fsf@alter.siamese.dyndns.org","threadId":"27196","inReplyTo":"20110427220748.GA19578@elie","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-27T23:27:07Z","receivedAt":"2011-04-27T23:27:07Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Junio C Hamano wrote:\n>\n>> For example, on my primary development box, I do not have any git\n>> installed from distribution, but I do have git on my $PATH. For such\n>> users, \"make install\" should be able to find out that the right place to\n>> install git-work.1 is in $HOME/some/where/man/man1 directory.\n>\n> Sorry to be dense, but: isn't the right place to install git-work.1\n> one of\n>\n> \t/usr/local/share/man\n> \t/usr/share/man\n> \t/opt/man\n> \t$HOME/man\n> \t$prefix/man\n>\n> depending on where the git-work binary was installed?\n\nI was thinking it, and the location git-work binary gets installed, should\ndepend on where \"git\" and its subcommand binaries are installed. The word\nplug-in mentioned in the thread implied that whatever plugs in is not by\nitself full fledged thing that is useful standalone, so it seemed a very\nnatural thing to do.\n\n> In the $prefix\n> case, the same snippet in .profile that adds $prefix/bin to the $PATH\n> would also say\n>\n> \tMANPATH=$prefix/man:$(manpath)\n\nYou are correct only if \"git\" the user is building is _not_ changed to\nlook for other places for its own manpages. If \"git\" was built to look at\nsomewhere else, the relationship between the output of \"git --exec-path\"\nand that location shouldn't be assumed to be ../../share/man or anything.\n\nThe layout should be discoverable, by exposing system_path(GIT_MAN_PATH)\nand friends (see builtin/help.c), just like we expose GIT_EXEC_PATH.\n\n> Or is the idea to blindly install (a symlink to) git-work to $(git\n> --exec-path)/ rather than a place on the $PATH?\n\nYou can call it _blindly_ if you like, but that is what I meant. \"git\"\ntells where the binary and help material for a \"plugin\" to be installed,\nso that it can find them where it expects to.\n\nAfter all, I am not interested at all in adding \"git pm\" or other crap. I\nam just trying to help people write their own \"make install\" of a plugin\nproject, like \"git work\". And writing \"make uninstall\" for that project\nshould be doable with the same information I am trying to give in this\nthread, no?\n"},{"id":"166575","messageId":"20110427234224.GA26854@elie","threadId":"27196","inReplyTo":"7vsjt35l84.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-27T23:42:24Z","receivedAt":"2011-04-27T23:42:24Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Junio C Hamano wrote:\n\n> I was thinking it, and the location git-work binary gets installed, should\n> depend on where \"git\" and its subcommand binaries are installed. The word\n> plug-in mentioned in the thread implied that whatever plugs in is not by\n> itself full fledged thing that is useful standalone, so it seemed a very\n> natural thing to do.\n\nWith the goal of making some commands available to git without putting\nthem on the $PATH in mind, this all makes more sense. Sorry I missed\nthat before.\n\n>> Or is the idea to blindly install (a symlink to) git-work to $(git\n>> --exec-path)/ rather than a place on the $PATH?\n>\n> You can call it _blindly_ if you like, but that is what I meant. \"git\"\n> tells where the binary and help material for a \"plugin\" to be installed,\n> so that it can find them where it expects to.\n\nRight, my worry was based on the usual way programs find their way\nonto my $PATH. That is:\n\n - if they are installed via a package from the distro, they are in\n /usr/bin.\n\n - if they are installed with \"make install\" by the local sysadmin for\n all users, they are in /usr/local/bin.\n\n - if I am trying them out for myself, they are in $HOME/opt/foo/bin\n and when it is time to remove it, \"rm -fr $HOME/opt/foo\".\n\n - if I have adopted them, symlinks go in $HOME/bin.\n\nWith a local gcc-4.6 in $HOME/bin, if the sysadmin upgrades gcc so\ngcc-4.6 is to appear in /usr/bin or /usr/local/bin, my setup still\nworks without trouble. So, barring bugs, each installation method\ndoes not interfere with the other ones.\n\nCall it overengineering, but I would want a way for installing new git\ncommands to have the same attributes (installable by normal users in\nmultiuser systems and name conflicts not being a terrible\nadministrative burden). A simple way would be to introduce\nGIT_MAN_PATH as you described and to teach \"git help\" to accept a\nGIT_EXEC_PATH consisting of a colon-delimited (semicolon-delimited on\nWindows) list of directories.\n"},{"id":"166576","messageId":"BANLkTin0=1LdvHgLebuSyUGmFRVzNGoVtg@mail.gmail.com","threadId":"27196","inReplyTo":"7vsjt35l84.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T00:06:36Z","receivedAt":"2011-04-28T00:06:36Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 9:27 AM, Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>\n>> Junio C Hamano wrote:\n>\n> I was thinking it, and the location git-work binary gets installed, should\n> depend on where \"git\" and its subcommand binaries are installed. The word\n> plug-in mentioned in the thread implied that whatever plugs in is not by\n> itself full fledged thing that is useful standalone, so it seemed a very\n> natural thing to do.\n>\n\nYou are correct about this - the ~/.git-pm/activation was, um, a horrible idea.\n\n>> In the $prefix\n>> case, the same snippet in .profile that adds $prefix/bin to the $PATH\n>> would also say\n>>\n>> MANPATH=$prefix/man:$(manpath)\n>\n> You are correct only if \"git\" the user is building is _not_ changed to\n> look for other places for its own manpages. If \"git\" was built to look at\n> somewhere else, the relationship between the output of \"git --exec-path\"\n> and that location shouldn't be assumed to be ../../share/man or anything.\n>\n> The layout should be discoverable, by exposing system_path(GIT_MAN_PATH)\n> and friends (see builtin/help.c), just like we expose GIT_EXEC_PATH.\n>\n>> Or is the idea to blindly install (a symlink to) git-work to $(git\n>> --exec-path)/ rather than a place on the $PATH?\n>\n> You can call it _blindly_ if you like, but that is what I meant. \"git\"\n> tells where the binary and help material for a \"plugin\" to be installed,\n> so that it can find them where it expects to.\n>\n\n> After all, I am not interested at all in adding \"git pm\" or other crap. I\n> am just trying to help people write their own \"make install\" of a plugin\n> project, like \"git work\". And writing \"make uninstall\" for that project\n> should be doable with the same information I am trying to give in this\n> thread, no?\n\nOk, how about this?\n\nplugins/\n gitwork/\n git-work.sh\n git-work.1\n\nlibexec/\n plugins/\n git-work -> ../../plugins/gitwork/git-work.sh\n\nshare/\n man/\n man1/\n git-work.1 -> ../../../plugins/git-work.1\n\nThe function of a:\n\n git plugin activate git-work\n\nwould simply be to establish the symlinks.\n\ngitwork would get into plugins/ by your existing platform manager or\nmake install do some minimal validation of conflicts, etc.\n\njon.\n"},{"id":"166577","messageId":"BANLkTikwyrwknzPmXwKMAsv5d6PUWSm6AQ@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTin0=1LdvHgLebuSyUGmFRVzNGoVtg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T00:08:39Z","receivedAt":"2011-04-28T00:08:39Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 10:06 AM, Jon Seymour wrote:\n\n>\n> gitwork would get into plugins/ by your existing platform manager or\n> make install do some minimal validation of conflicts, etc.\n>\n\nSorry, garbled\n\nI meant:\n\ngitwork would get into plugins/ via the path of an existing platform\nmanager or make install.\n\nOne function of git plugin activate would be to perform some minimal\nvalidation to report on and/or prevent conflicts.\n\njon.\n"},{"id":"166578","messageId":"7viptz5j82.fsf@alter.siamese.dyndns.org","threadId":"27196","inReplyTo":"20110427234224.GA26854@elie","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-04-28T00:10:21Z","receivedAt":"2011-04-28T00:10:21Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jonathan Nieder writes:\n\n> Right, my worry was based on the usual way programs find their way\n> onto my $PATH. That is:\n>\n> - if they are installed via a package from the distro, they are in\n> /usr/bin.\n>\n> - if they are installed with \"make install\" by the local sysadmin for\n> all users, they are in /usr/local/bin.\n>\n> - if I am trying them out for myself, they are in $HOME/opt/foo/bin\n> and when it is time to remove it, \"rm -fr $HOME/opt/foo\".\n>\n> - if I have adopted them, symlinks go in $HOME/bin.\n>\n> With a local gcc-4.6 in $HOME/bin, if the sysadmin upgrades gcc so\n> gcc-4.6 is to appear in /usr/bin or /usr/local/bin, my setup still\n> works without trouble. So, barring bugs, each installation method\n> does not interfere with the other ones.\n>\n> Call it overengineering, but I would want a way for installing new git\n> commands to have the same attributes (installable by normal users in\n> multiuser systems and name conflicts not being a terrible\n> administrative burden).\n\nOk, I wasn't thinking about folks who use repackaged /usr/bin/git together\nwith their own choice of third-party enhancements.\n\nProbably we would be better off if we define a new set of paths that is\nindependent from GIT_EXEC_PATH and friends. The installed git and nothing\nelse will occupy GIT_EXEC_PATH etc., but at the runtime, git would look at\na user-writable location GIT_PLUGIN_PATH/{bin,man,...} to see if the user\nhas her own customization, and add them to its vocabulary.\n\nOr something like that. I am not all that interested, but it feels like a\ngood direction.\n"},{"id":"166580","messageId":"BANLkTi=w0aKH6dxu84i4DjkL-vNCWQi8pw@mail.gmail.com","threadId":"27196","inReplyTo":"7viptz5j82.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T00:50:47Z","receivedAt":"2011-04-28T00:50:47Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 10:10 AM, Junio C Hamano wrote:\n> Jonathan Nieder writes:\n>\n>> Right, my worry was based on the usual way programs find their way\n>> onto my $PATH.  That is:\n>>\n>>  - if they are installed via a package from the distro, they are in\n>>    /usr/bin.\n>>\n>>  - if they are installed with \"make install\" by the local sysadmin for\n>>    all users, they are in /usr/local/bin.\n>>\n>>  - if I am trying them out for myself, they are in $HOME/opt/foo/bin\n>>    and when it is time to remove it, \"rm -fr $HOME/opt/foo\".\n>>\n>>  - if I have adopted them, symlinks go in $HOME/bin.\n>>\n>> With a local gcc-4.6 in $HOME/bin, if the sysadmin upgrades gcc so\n>> gcc-4.6 is to appear in /usr/bin or /usr/local/bin, my setup still\n>> works without trouble.  So, barring bugs, each installation method\n>> does not interfere with the other ones.\n>>\n>> Call it overengineering, but I would want a way for installing new git\n>> commands to have the same attributes (installable by normal users in\n>> multiuser systems and name conflicts not being a terrible\n>> administrative burden).\n>\n> Ok, I wasn't thinking about folks who use repackaged /usr/bin/git together\n> with their own choice of third-party enhancements.\n>\n> Probably we would be better off if we define a new set of paths that is\n> independent from GIT_EXEC_PATH and friends.  The installed git and nothing\n> else will occupy GIT_EXEC_PATH etc., but at the runtime, git would look at\n> a user-writable location GIT_PLUGIN_PATH/{bin,man,...} to see if the user\n> has her own customization, and add them to its vocabulary.\n>\n> Or something like that.  I am not all that interested, but it feels like a\n> good direction.\n>\n\nI agree. Apologies for confusing things by talking too much about a\ngit pm install command.\n\nI think there are 3 levels of functionality. FWIW, I am suggesting\ngit-core stops at #2.\n\n0. unmanaged plugins\n\ngit doesn't provide any explicit management of plugins, but will use\nthem if finds them.\n\nWithout some kind of management, however, you will be forced to dump\nthe man pages and scripts\nfor the plugins in one place.\n\nThis would be very distribution manager unfriendly since there could\nbe conflicts galore.\n\nI guess an unmanaged solution could use separate directories for each\nplugin, but this would imply scanning all these paths each time you\ninvoke git. In my view, symbolic links from a dir already\nGIT_EXEC_PATH to plugin directories would be a more efficient way to\ndo this.\n\n1. managed plugins\n\ngit provides minimal plugin management functionality. Each plugin has\nits own directory, but an activate step is required to make the plugin\navailable to the GIT_EXEC_PATH and GIT_MAN_PATH.\n\nThis has the advantage that conflicts between plugins would be more\nreadily avoided and is potentially more performant. As Pau suggests,\nthis option is much more package manager friendly\n\nIt probably does require a git plugin command of some kind, however,\nin order to perform the activation step.\n\n2. managed packages\n\nA meta-package manager for plugins, that delegates plugin installation\nconcerns to a platform package manager.\n\nThe thing is, you may absolutely hate #2, but if approach #1 is\nadopted by git-core, someone can at least attempt this by, well,\nwriting a plugin for it.\n\njon.\n"},{"id":"166581","messageId":"BANLkTikCKDS3NhbpnRqf82c_oB4+JqGX-Q@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTi=w0aKH6dxu84i4DjkL-vNCWQi8pw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T00:54:46Z","receivedAt":"2011-04-28T00:54:46Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 10:50 AM, Jon Seymour wrote:\n> On Thu, Apr 28, 2011 at 10:10 AM, Junio C Hamano wrote:\n>> Jonathan Nieder writes:\n>>\n>>> Right, my worry was based on the usual way programs find their way\n>>> onto my $PATH.  That is:\n>>>\n>>>  - if they are installed via a package from the distro, they are in\n>>>    /usr/bin.\n>>>\n>>>  - if they are installed with \"make install\" by the local sysadmin for\n>>>    all users, they are in /usr/local/bin.\n>>>\n>>>  - if I am trying them out for myself, they are in $HOME/opt/foo/bin\n>>>    and when it is time to remove it, \"rm -fr $HOME/opt/foo\".\n>>>\n>>>  - if I have adopted them, symlinks go in $HOME/bin.\n>>>\n>>> With a local gcc-4.6 in $HOME/bin, if the sysadmin upgrades gcc so\n>>> gcc-4.6 is to appear in /usr/bin or /usr/local/bin, my setup still\n>>> works without trouble.  So, barring bugs, each installation method\n>>> does not interfere with the other ones.\n>>>\n>>> Call it overengineering, but I would want a way for installing new git\n>>> commands to have the same attributes (installable by normal users in\n>>> multiuser systems and name conflicts not being a terrible\n>>> administrative burden).\n>>\n>> Ok, I wasn't thinking about folks who use repackaged /usr/bin/git together\n>> with their own choice of third-party enhancements.\n>>\n>> Probably we would be better off if we define a new set of paths that is\n>> independent from GIT_EXEC_PATH and friends.  The installed git and nothing\n>> else will occupy GIT_EXEC_PATH etc., but at the runtime, git would look at\n>> a user-writable location GIT_PLUGIN_PATH/{bin,man,...} to see if the user\n>> has her own customization, and add them to its vocabulary.\n>>\n>> Or something like that.  I am not all that interested, but it feels like a\n>> good direction.\n>>\n>\n> I agree. Apologies for confusing things by talking too much about a\n> git pm install command.\n>\n> I think there are 3 levels of functionality. FWIW, I am suggesting\n> git-core stops at #2.\n>\n> 0. unmanaged plugins\n>\n> git doesn't provide any explicit management of plugins, but will use\n> them if finds them.\n>\n> Without some kind of management, however, you will be forced to dump\n> the man pages and scripts\n> for the plugins in one place.\n>\n> This would be very distribution manager unfriendly since there could\n> be conflicts galore.\n>\n> I guess an unmanaged solution could use separate directories for each\n> plugin, but this would imply scanning all these paths each time you\n> invoke git. In my view, symbolic links from a dir already\n> GIT_EXEC_PATH to plugin directories would be a more efficient way to\n> do this.\n>\n> 1. managed plugins\n>\n> git provides minimal plugin management functionality. Each plugin has\n> its own directory, but an activate step is required to make the plugin\n> available to the GIT_EXEC_PATH and GIT_MAN_PATH.\n>\n> This has the advantage that conflicts between plugins would be more\n> readily avoided and is potentially more performant. As Pau suggests,\n> this option is much more package manager friendly\n>\n> It probably does require a git plugin command of some kind, however,\n> in order to perform the activation step.\n>\n> 2. managed packages\n>\n> A meta-package manager for plugins, that delegates plugin installation\n> concerns to a platform package manager.\n>\n> The thing is, you may absolutely hate #2, but if approach #1 is\n> adopted by git-core, someone can at least attempt this by, well,\n> writing a plugin for it.\n>\n\nSorry, sorry/. git-core stops at #1!!\n\n> jon.\n>\n"},{"id":"166582","messageId":"alpine.DEB.2.00.1104271751300.940@asgard.lang.hm","threadId":"27196","inReplyTo":"BANLkTi=w0aKH6dxu84i4DjkL-vNCWQi8pw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2011-04-28T00:55:58Z","receivedAt":"2011-04-28T00:55:58Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 28 Apr 2011, Jon Seymour wrote:\n\n> On Thu, Apr 28, 2011 at 10:10 AM, Junio C Hamano wrote:\n>> Jonathan Nieder writes:\n>>\n>\n> I agree. Apologies for confusing things by talking too much about a\n> git pm install command.\n>\n> I think there are 3 levels of functionality. FWIW, I am suggesting\n> git-core stops at #2.\n>\n> 0. unmanaged plugins\n>\n> git doesn't provide any explicit management of plugins, but will use\n> them if finds them.\n>\n> Without some kind of management, however, you will be forced to dump\n> the man pages and scripts\n> for the plugins in one place.\n>\n> This would be very distribution manager unfriendly since there could\n> be conflicts galore.\n\nevery package manager I know of has no problem with multiple packages \nowning files in one directory.\n\nif the files are named the same thing you will have a conflict, but if the \nfiles are named the same thing, the commands are probably going to be \nnamed the same, and so you will have conflicts in any case.\n\n> I guess an unmanaged solution could use separate directories for each\n> plugin, but this would imply scanning all these paths each time you\n> invoke git. In my view, symbolic links from a dir already\n> GIT_EXEC_PATH to plugin directories would be a more efficient way to\n> do this.\n\nI think you are overanalyzing the problem\n\n> 1. managed plugins\n>\n> git provides minimal plugin management functionality. Each plugin has\n> its own directory, but an activate step is required to make the plugin\n> available to the GIT_EXEC_PATH and GIT_MAN_PATH.\n>\n> This has the advantage that conflicts between plugins would be more\n> readily avoided and is potentially more performant. As Pau suggests,\n> this option is much more package manager friendly\n\nI don't see how this will avoid conflicts. what files are you thinking \nthat the different plugins will make that won't conflict any more than the \ncommands themselves will?\n\n> It probably does require a git plugin command of some kind, however,\n> in order to perform the activation step.\n\nonly if you think you need a 'installed but not active' mode of operation, \nand I don't understand why you would want that.\n\nDavid Lang\n\n> 2. managed packages\n>\n> A meta-package manager for plugins, that delegates plugin installation\n> concerns to a platform package manager.\n>\n> The thing is, you may absolutely hate #2, but if approach #1 is\n> adopted by git-core, someone can at least attempt this by, well,\n> writing a plugin for it.\n>\n> jon.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"166591","messageId":"BANLkTimnkBMRH7Spj1ByQRa9YdV9w+bwtQ@mail.gmail.com","threadId":"27196","inReplyTo":"alpine.DEB.2.00.1104271751300.940@asgard.lang.hm","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T02:08:23Z","receivedAt":"2011-04-28T02:08:23Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 10:55 AM, wrote:\n> On Thu, 28 Apr 2011, Jon Seymour wrote:\n>\n>> On Thu, Apr 28, 2011 at 10:10 AM, Junio C Hamano \n>> wrote:\n>>>\n>>> Jonathan Nieder writes:\n>>>\n>>\n>> I agree. Apologies for confusing things by talking too much about a\n>> git pm install command.\n>>\n>> I think there are 3 levels of functionality. FWIW, I am suggesting\n>> git-core stops at #2.\n>>\n>> 0. unmanaged plugins\n>>\n>> git doesn't provide any explicit management of plugins, but will use\n>> them if finds them.\n>>\n>> Without some kind of management, however, you will be forced to dump\n>> the man pages and scripts\n>> for the plugins in one place.\n>>\n>> This would be very distribution manager unfriendly since there could\n>> be conflicts galore.\n>\n> every package manager I know of has no problem with multiple packages owning\n> files in one directory.\n>\n> if the files are named the same thing you will have a conflict, but if the\n> files are named the same thing, the commands are probably going to be named\n> the same, and so you will have conflicts in any case.\n>\n\nSuppose a plugin contains a file called LICENSE or README.txt. Which\nLICENSE or README.txt wins?\n\n>> I guess an unmanaged solution could use separate directories for each\n>> plugin, but this would imply scanning all these paths each time you\n>> invoke git. In my view, symbolic links from a dir already\n>> GIT_EXEC_PATH to plugin directories would be a more efficient way to\n>> do this.\n>\n> I think you are overanalyzing the problem\n\nI don't think so. Perhaps Pau can give us his view on the\ndesirability of a single directory for all plugins artifacts from a\ndistribution maintainers perspective.\n\n>> 1. managed plugins\n>>\n>> git provides minimal plugin management functionality. Each plugin has\n>> its own directory, but an activate step is required to make the plugin\n>> available to the GIT_EXEC_PATH and GIT_MAN_PATH.\n>>\n>> This has the advantage that conflicts between plugins would be more\n>> readily avoided and is potentially more performant. As Pau suggests,\n>> this option is much more package manager friendly\n>\n> I don't see how this will avoid conflicts. what files are you thinking that\n> the different plugins will make that won't conflict any more than the\n> commands themselves will?\n\nNo, but you can manage the conflicts. Hence _managed_ plugins.\n\n git plugin activate\n\ncan fail with a non-zero exit code if there will be a conflict.\n\n>\n>> It probably does require a git plugin command of some kind, however,\n>> in order to perform the activation step.\n>\n> only if you think you need a 'installed but not active' mode of operation,\n> and I don't understand why you would want that.\n>\n\nFor the reasons of managed conflict management.\n\nI don't want to drop a new plugin into a common directory only to find\nit has blitzed some other plugin I previously did the same with.\n\nStill, I guess it is horses for courses.\n\njon.\n"},{"id":"166592","messageId":"BANLkTikbcpzF203rUVB05OYyYhLmu3+n6w@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTimnkBMRH7Spj1ByQRa9YdV9w+bwtQ@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T02:15:19Z","receivedAt":"2011-04-28T02:15:19Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"Assuming for the moment that the concept of a managed plugin is accepted, then.\n\nThe relationship between distribution managers and the git-plugin\narchitecture would be as follows:\n\n- distributions would know how to locate the git instance it manages\n- distributions would know how to install their own packages that\ncontain plugins into plugins/ subdirectory of this git instance\n- distributions would know how to run git plugin activate and properly\nhandle non-zero return codes from same\n\nmake install scripts would act like a kind of distribution in this regard.\n\nNow consider this:\n\n* suppose that git-core defined a git install _interface contract_ but\ndid not define an implementation.\n\nThen, a distribution could install its own implementation of the\ngit-install plugin into git installations it manages.\n\nThen a command like:\n\n git install gitwork\n\nwould trivially work across all distributions precisely because the\ndistribution has provided the implementation of the git install\ninterface contract that git-core has helpfully mandated.\n\njon.\n"},{"id":"166594","messageId":"BANLkTinQny-M0rL+Vs9L_cQhtVLyv6rqMw@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTikbcpzF203rUVB05OYyYhLmu3+n6w@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T02:49:21Z","receivedAt":"2011-04-28T02:49:21Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 12:15 PM, Jon Seymour wrote:\n> Then a command like:\n>\n>    git install gitwork\n>\n> would trivially work across all distributions precisely because the\n> distribution has provided the implementation of the git install\n> interface contract that git-core has helpfully mandated.\n>\n\nOr better yet, git-core could provide a trivial git install\nimplementation that selects between different distribution manager\nsupplied plugins selected according to some heuristic, allowing\nseveral distribution managers to happily manage plugins in the same\ngit instance.\n\nI have to ask.\n\nIs such an architecture really \"absolutely horrid\"? Is it \"crap\"? Really?\n\njon.\n"},{"id":"166595","messageId":"BANLkTimyFmujc+Lsd7DMWfJgUzZME+Sveg@mail.gmail.com","threadId":"27196","inReplyTo":"4DB84D65.6070906@gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T03:07:48Z","receivedAt":"2011-04-28T03:07:48Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 3:07 AM, A Large Angry SCM wrote:\n>\n> For a git plugin ecosystem to work, a (relatively) stable API/ABI is\n> necessary for the plugin authors to code to. Where is your proposal for\n> that.\n>\n\nTo answer your question, the intent is to provide plugins git's\ncommand line interface.\n\nAs has already explained by Junio amongst others, git already provides\nsupport for such extensions via its idiom of treating any executable\nof the form git-{command} found in the PATH.\n\nThe intention of my proposal is simply to formalise the plugin\narchitecture and provide a degree of plugin management.\n\nOf course, others might think there is a need for ABI plugins, and\nthey are free to propose such extensions, but that is not my intent.\n\njon.\n"},{"id":"166596","messageId":"BANLkTi=vJeUAwMH0Fa7SXmK=2hwu8vnPGg@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTimyFmujc+Lsd7DMWfJgUzZME+Sveg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T03:26:08Z","receivedAt":"2011-04-28T03:26:08Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"Just in case other people haven't noticed...\n\nA sane plugin management architcture also provides a sane way to\nmanage hooks that might contributed my multiple parties and to provide\na sane way to deal with conflicts between same in a\ndistribution-agnostic manner.\n\njon.\n"},{"id":"166598","messageId":"BANLkTi=-RYfUrPt+LkUA9GA6_vmTzVkQnQ@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTi=vJeUAwMH0Fa7SXmK=2hwu8vnPGg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T05:04:03Z","receivedAt":"2011-04-28T05:04:03Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"The concept of a division of responsibilities between 3 roles seems to\nbe misunderstood.\n\nThere are 3 roles:\n\n application, plugin and package.\n\nThe application provides the plugin manager.\nThe disribution provides the package manager.\nThe package manager packages the plugin as a OS-specific package.\nThe package manager installs the package, containing the plugin.\nThe package manager calls the application's plugin manager to activate\nthe plugin\n\nOptionally, the application delegates plugin installation request to\none or more package managers.\n\nSimple, isn't it?\n\nRuby (and to be honest, npm) got it wrong because they have a plugin\nmanager that wants to be a package manager.\n\n\njon.\n"},{"id":"166599","messageId":"BANLkTimaWr1FA154p87KZM7NT+2CQTuYZQ@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTi=-RYfUrPt+LkUA9GA6_vmTzVkQnQ@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T06:15:10Z","receivedAt":"2011-04-28T06:15:10Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"FWIW: I have renamed my github package from gpm to git-plugin.\n\nContributors who grok the concept as I conceive it are welcome to\nsubmit pull requests.\n\njon.\n\nhttps://github.com/jonseymour/git-plugin\n"},{"id":"166603","messageId":"BANLkTi=VLKoKxib+_NDOJYKL-R=AZWDi6g@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTimnkBMRH7Spj1ByQRa9YdV9w+bwtQ@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Pau Garcia i Quiles","fromEmail":"pgquiles@elpauer.org","sentAt":"2011-04-28T07:40:08Z","receivedAt":"2011-04-28T07:40:08Z","isPatch":false,"sender":{"key":"pgquiles@elpauer.org","avatar":null},"body":"On Thu, Apr 28, 2011 at 4:08 AM, Jon Seymour wrote:\n\n>>> I guess an unmanaged solution could use separate directories for each\n>>> plugin, but this would imply scanning all these paths each time you\n>>> invoke git. In my view, symbolic links from a dir already\n>>> GIT_EXEC_PATH to plugin directories would be a more efficient way to\n>>> do this.\n>>\n>> I think you are overanalyzing the problem\n>\n> I don't think so.  Perhaps Pau can give us his view on the\n> desirability of a single directory for all plugins artifacts from a\n> distribution maintainers perspective.\n\nYou are thinking too much, this is simpler than what you are trying to do :-)\n\nWhat packages in Linux distributions do is essentially placing files\nwhere the FHS says, i. e:\n\n- Binaries intended to be used by an average Joe go to /usr/bin\n- Binaries for internal consumption go to /usr/lib/packagename\n- Libraries go to /usr/lib\n- Documentation goes to /usr/share/doc/packagename\n- Manual pages to go /usr/share/man/manX/command.X.gz\n- etc\n\nDefine something like that inside the prefix where git is installed\nand you are done. As Junio said, git already checks for git-* presence\nfor help, etc.\n\nIf you want to see more about package organization, go to\nhttp://www.debian.org/Packages/unstable/ , go to that package's page\nand at the bottom there is a \"List of files\" link. For instance\n\nhttp://packages.debian.org/experimental/git\nhttp://packages.debian.org/experimental/amd64/git/filelist\n\nBTW, I fail to see why an \"activation\" step is needed. Either it is\ninstalled or it is not.\n\n-- \nPau Garcia i Quiles\nhttp://www.elpauer.org\n(Due to my workload, I may need 10 days to answer)\n"},{"id":"166604","messageId":"BANLkTi=skWHp+ALSqg9BOTqAjqw5Si_-4Q@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTi=VLKoKxib+_NDOJYKL-R=AZWDi6g@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T08:09:19Z","receivedAt":"2011-04-28T08:09:19Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 5:40 PM, Pau Garcia i Quiles\n wrote:\n> On Thu, Apr 28, 2011 at 4:08 AM, Jon Seymour wrote:\n>\n>>>> I guess an unmanaged solution could use separate directories for each\n>>>> plugin, but this would imply scanning all these paths each time you\n>>>> invoke git. In my view, symbolic links from a dir already\n>>>> GIT_EXEC_PATH to plugin directories would be a more efficient way to\n>>>> do this.\n>>>\n>>> I think you are overanalyzing the problem\n>>\n>> I don't think so.  Perhaps Pau can give us his view on the\n>> desirability of a single directory for all plugins artifacts from a\n>> distribution maintainers perspective.\n>\n> You are thinking too much, this is simpler than what you are trying to do :-)\n>\n> What packages in Linux distributions do is essentially placing files\n> where the FHS says, i. e:\n>\n> - Binaries intended to be used by an average Joe go to /usr/bin\n> - Binaries for internal consumption go to /usr/lib/packagename\n> - Libraries go to /usr/lib\n> - Documentation goes to /usr/share/doc/packagename\n> - Manual pages to go /usr/share/man/manX/command.X.gz\n> - etc\n>\n> Define something like that inside the prefix where git is installed\n> and you are done. As Junio said, git already checks for git-* presence\n> for help, etc.\n>\n> If you want to see more about package organization, go to\n> http://www.debian.org/Packages/unstable/ , go to that package's page\n> and at the bottom there is a \"List of files\" link. For instance\n>\n> http://packages.debian.org/experimental/git\n> http://packages.debian.org/experimental/amd64/git/filelist\n>\n> BTW, I fail to see why an \"activation\" step is needed. Either it is\n> installed or it is not.\n>\n> --\n> Pau Garcia i Quiles\n> http://www.elpauer.org\n> (Due to my workload, I may need 10 days to answer)\n>\n\nOk, I have tried to explain why separating the concerns of package\nmanagement and plugin management is an appropriate thing to do, and\nwhy one directory for each plugin is also a good thing to do. BTW: I\nthought you actually suggested this concept yourself in your earlier\npost.\n\nI also explained why an activation step is desirable. It is good for\nperformance (since you don't have to resolve across plugin directories\non each invocation) and it is good for conflict management (since you\nget a precise means to identify and prevent conflicts). More over, the\napplication which provides the plugin manager gets to do this conflict\ndetection and prevention, which is exactly the right component to do\nit. Why? because it understands its own plugin architecture better\nthan any and all plugin authors, package authors or package managers.\n\nThere is probably only so many times I can explain these principles.\n\nAs they saying goes - code talks. I'll implement things as I think\nthey should be implemented, incorporating the constructive suggestions\nthat have been made.\n\nTo be sure, even the insults have helped.\n\nCalling the idea of:\n\n git install foobar\n\n\"horrid\" and then \"utterly horrid\" and then \"crap\" has just helped\ncrystalise in my mind exactly where the correct lines of\nresponsibility should be drawn between, application, plugin and\npackage.\n\nIt appears that many people still don't get it but there is only so\nmuch I can do about that.\n\nAnyway, thanks for all your help (constructive and otherwise),\n\njon.\n"},{"id":"166607","messageId":"4DB92E35.4010402@op5.se","threadId":"27196","inReplyTo":"BANLkTikSsoCP_d34wdBHX=r336zJSHSWEQ@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-04-28T09:07:01Z","receivedAt":"2011-04-28T09:07:01Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 04/28/2011 12:32 AM, Jon Seymour wrote:\n> On Thu, Apr 28, 2011 at 8:08 AM, Jonathan Nieder wrote:\n>> Junio C Hamano wrote:\n> \n>> Or is the idea to blindly install (a symlink to) git-work to $(git\n>> --exec-path)/ rather than a place on the $PATH? In this case, I would\n>> be a little worried. How will the helper deal with uninstallation and\n>> with namespace conflicts? (On the $PATH, these are expected problems\n>> and I'd expect each user has some way of dealing with them already.)\n> \n> I see 'git pm activate' managing symbolic links in a directory\n> dedicated to the purpose (.e.g. ~/.git-pm/activated).\n> \n\nWhy not just flip executable bits on commands in the git directory?\nThat way, built-ins can't be disabled no matter what you type, and the\nlist of out-of-core helpers will be kept shorter.\n\nEither way, the \"activate\" thing requires you to maintain state of\ndownloaded extensions that aren't part of the core package. I'd say\nit's safe to assume that anything downloaded is supposed to be active\nand deactivating it is done by means of uninstalling it.\n\n> One thing 'git pm activate' could do is check that the commands\n> exported by the 'gitwork' descriptor do not conflict with what is\n> already activated.\n> \n> If the user has done something like:\n> \n> git clone https://repo/gitwork.git ~/hub/gitwork\n> \n> and then:\n> \n> git activate pm ~/hub/gitwork\n> \n> the symbolic links would be established to ~/hub/gitwork, wherever\n> that happens to be.\n> \n> If the user has done:\n> \n> apt-get install gitwork\n> \n> then given a package-manager adapter for apt-get, it could extract the\n> .gpm file from the list of installed files, and resume activation from\n> there. Ultimately, the end result is the same ~/.git-pm/activated is\n> updated, it has always been on the paths it needs to be.\n> \n> If the descriptor did have a list of exported commands (e.g. git-work,\n> git-base, git-atomic, git-test), then a global registry could use this\n> list of exported commands to detect conflicts early - at package\n> registration time which might help avoid grief down the track.\n\nBut seriously. Don't you see how complex this is? If you want to make\nthings easier for people, put up a website or a database somewhere and\nship a (very, very small) addon with core git that just goes to fetch\nthat list and present it to users upon request. The list should contain\n3 fields and 3 fields only.\n1. Short name of extension (must be unique)\n2. Url for where to get the extension\n3. Free-form text, containing info of why anyone would want to use it,\n preferrably in the style of git.git commit messages so the brief\n description is the first line and the full info comes later.\n\nThen your extension manager becomes really straightforward and can\neasily be extended over time to also uninstall applications.\n\nThis assumes that git core itself can provide paths for where the\nuser wants man-pages and whatnot, ofcourse, but such a patch is so\ntrivial anyone who's seen code in any language can easily hack it\nup blindfolded. Even for versions that doesn't support it, the man-\npages of any extension can be guessed from the --exec-path or just\nignored and all of them put into /usr/share/man or whatever the path\nmight be on the system we're on, so long as the extension manager\nremembers where they ended up. This could easily be handled by the\nextension itself creating a manifest file after it's done installing\nwhich is stashed away by the extension manager.\n\nA decent first step would be to have \"git pm list\" just show\nwhat extensions are available, what they do and where to get them.\n\nHowever, that info could just as easily be distributed to users by\nletting \"git help\" or something print a link to a wiki page and by\nletting extension devs know about some officially blessed way of\ninstalling and uninstalling extensions properly. Once all extensions\nuse that same way and there are more than a small handful of\nextensions, the idea of having a script download and automagically\ninstall those extensions will probably be opened up again, but by\nthen with more than a single user backing it up with a request that\nit be implemented (without showing any code).\n\nShipping a bunch of extensions with git core or making distro package\nmaintainers ship them as deactivated by default makes absolutely no\nsense what so ever. Shipping a (very small) extension manager with\ngit that aids users obtaining more extensions makes sense when there's\na proper flora of them rather than just a few.\n\nEither way, it's time to put your money where your mouth is and show\nus some code that does what you think is a good idea.\n\nIf I were you, I'd start with the blindfolded patch mentioned above\nand then follow up with a configurable directory where git will\nsearch for additional commands, with a sensible default in the\nuser's home directory (.git-plugins, perhaps?).\n\nLet conflicts go hang for now. They will be thoroughly frowned upon\nby the community anyway, since providing any sort of help for the\ncommand \"git fniggle\" will be totally impossible if there are 100\ndifferent implementations of it.\n \nWith those two patches in place in core git (which I'm fairly sure\nJunio won't reject out of hand given his opinions in this thread),\ncoding up the \"make install\" part of extensions become trivial and\nstarting on the real extension manager becomes at least possible for\nboth types of core git users, namely:\n1. Those who get core git from yum/brew/apt-get\n2. Those who build it from sources.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"166609","messageId":"BANLkTi=b3bSt8VUvFJw2TiXZNXf0+wLj+Q@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTi=skWHp+ALSqg9BOTqAjqw5Si_-4Q@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Pau Garcia i Quiles","fromEmail":"pgquiles@elpauer.org","sentAt":"2011-04-28T09:11:16Z","receivedAt":"2011-04-28T09:11:16Z","isPatch":false,"sender":{"key":"pgquiles@elpauer.org","avatar":null},"body":"On Thu, Apr 28, 2011 at 10:09 AM, Jon Seymour wrote:\n\n> Ok, I have tried to explain why separating the concerns of package\n> management and plugin management is an appropriate thing to do, and\n> why one directory for each plugin is also a good thing to do. BTW: I\n> thought you actually suggested this concept yourself in your earlier\n> post.\n\nPlease, re-read my mails. I *am* suggesting that plugins store data in\ndifferent directories!\n\n- The \"main command\" (git-atomic, for instance) would be stored in\nGIT_PREFIX/lib/git-plugins (instead of GIT_PREFIX/lib/git-core, which\nis where git stores its commands). Git would have to learn to search\nin GIT_PREFIX/lib/git-plugins in addition to git-core, of course.\n\n- Porcelain for git-atomic would go to\nGIT_PREFIX/lib/git-plugins/git-atomic (or something like this)\n\n- The documentation would be stored in GIT_PREFIX/doc/git-atomic\n\n- Resources in GIT_PREFIX/share/git-atomic\n\n- etc\n\nI. e. each plugin stores its stuff in a separate directory, it's just\nthat directory is not a *single* directory but *many* directories,\neach one inside the proper path under GIT_PREFIX, just like it is for\nanything you install on a Unix system\n\n-- \nPau Garcia i Quiles\nhttp://www.elpauer.org\n(Due to my workload, I may need 10 days to answer)\n"},{"id":"166610","messageId":"4DB92F55.5090409@op5.se","threadId":"27196","inReplyTo":"BANLkTikbcpzF203rUVB05OYyYhLmu3+n6w@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-04-28T09:11:49Z","receivedAt":"2011-04-28T09:11:49Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 04/28/2011 04:15 AM, Jon Seymour wrote:\n> Assuming for the moment that the concept of a managed plugin is accepted, then.\n> \n> The relationship between distribution managers and the git-plugin\n> architecture would be as follows:\n> \n> - distributions would know how to locate the git instance it manages\n> - distributions would know how to install their own packages that\n> contain plugins into plugins/ subdirectory of this git instance\n> - distributions would know how to run git plugin activate and properly\n> handle non-zero return codes from same\n> \n> make install scripts would act like a kind of distribution in this regard.\n> \n> Now consider this:\n> \n> * suppose that git-core defined a git install _interface contract_ but\n> did not define an implementation.\n> \n\nPlease. I'm already on my way to a seriously boring sales meeting without\nhaving developers throw garbage terms on me. You've done a lot of that in\nthis thread and I for one am confused by them as to what you want to\nachieve and how you want to achieve it.\n\n> Then, a distribution could install its own implementation of the\n> git-install plugin into git installations it manages.\n> \n> Then a command like:\n> \n> git install gitwork\n> \n> would trivially work across all distributions precisely because the\n> distribution has provided the implementation of the git install\n> interface contract that git-core has helpfully mandated.\n> \n\nAnd so we force package maintainers to become git extension developers.\nBrilliant. They'll love you for it.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"166612","messageId":"4DB9329E.7000703@op5.se","threadId":"27196","inReplyTo":"BANLkTinQny-M0rL+Vs9L_cQhtVLyv6rqMw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2011-04-28T09:25:50Z","receivedAt":"2011-04-28T09:25:50Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"On 04/28/2011 04:49 AM, Jon Seymour wrote:\n> On Thu, Apr 28, 2011 at 12:15 PM, Jon Seymour wrote:\n>> Then a command like:\n>>\n>> git install gitwork\n>>\n>> would trivially work across all distributions precisely because the\n>> distribution has provided the implementation of the git install\n>> interface contract that git-core has helpfully mandated.\n>>\n> \n> Or better yet, git-core could provide a trivial git install\n> implementation that selects between different distribution manager\n> supplied plugins selected according to some heuristic, allowing\n> several distribution managers to happily manage plugins in the same\n> git instance.\n> \n> I have to ask.\n> \n> Is such an architecture really \"absolutely horrid\"? Is it \"crap\"? Really?\n> \n\nYes, because it forces all distributions to name their extensions\nthe same and it forces all distributions to carry the same extensions.\nIt also makes it impossible to support 3rd party extensions that core\ngit doesn't know about and that aren't already packaged, unless you\nwant the \"git install\" command to have knowledge about all package\nmanagement systems and *very, very good* heuristics when guessing what\na particular extension is called on that system.\n\nWhat will happen though is that the distributions will happily ignore\nthat and the \"git install\" command will fail for some extensions on\nsome distributions.\n\nBesides that, it forces users to install git from their distribution\npackages so we're hard-shafting the git developers who usually have\nat least some installations done from source.\n\nWe just went far beyond \"absolutely horrid\" and into the realms of\n\"steaming pile of abominably manure-like ideas whose inventor should\nbe slapped silly for their own good\".\n\nSo let's get back to the basic wish you have here. You want people\nto be able to easily find, download and install \"git work\" so that it\nworks nicely with man-pages and all.\n\nThe wiki-page with known extensions and the patch to core git so that\n\"make install\" can put man-pages in the right directory are the first,\nsimplest and smallest steps that takes us the farthest towards that\nwish without burdening people you have no control over with more labor.\nIn short; It's both good engineering and polite to implement that and\nthen consider what new possibilities open up and see what people do\nwith those possibilities. You might be surprised.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n\nConsidering the successes of the wars on alcohol, poverty, drugs and\nterror, I think we should give some serious thought to declaring war\non peace.\n"},{"id":"166620","messageId":"BANLkTin2Ts5C=Sp60w7xnkJ078MaNiroVw@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTi=b3bSt8VUvFJw2TiXZNXf0+wLj+Q@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T09:42:43Z","receivedAt":"2011-04-28T09:42:43Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thursday, April 28, 2011, Pau Garcia i Quiles wrote:\n> On Thu, Apr 28, 2011 at 10:09 AM, Jon Seymour wrote:\n>\n>> Ok, I have tried to explain why separating the concerns of package\n>> management and plugin management is an appropriate thing to do, and\n>> why one directory for each plugin is also a good thing to do. BTW: I\n>> thought you actually suggested this concept yourself in your earlier\n>> post.\n>\n> Please, re-read my mails. I *am* suggesting that plugins store data in\n> different directories!\n\nGood. Sorry I explained why an activation step is good for\nperformance, particularly if you have a plugin architecture that uses\nmultiple directories, one per plugin. I misinterpreted your confusion\nabout why an activate step was necessary as an explicit rejection of\nmy arguments that an activation step was a plus for performance and\nconflict detection in an environment in which each plugin is installed\nin it's own directory. Apologies.\n\nSupposed you have 100 plugins. Suppose the user invoked git foobar\nwhere foobar is an installed plugin. How does git find the plugin to\ninvoke? Why it has to scan 100 directories looking for a match.\n\nIf you use an activation step (just after installation) you get O(1)\nperformance instead of O(n). Small gain for 2 plugins, I agree.\n\nBut then that isn't the only reason to use an activation step. As I\nsaid, an activation step alllows precise detection and prevention of\nconflicts that just isn't possible if you rely on first-in-PATH\nsemantics.\n\nIt is true, you can delegate conflict detection to the package\nmanager, but do you know what, that would be in Andreas\"s words\n\"Brilliant\" as it would force package maintainers become git extension\nexperts.\n\nMy proposal makes the git-core maintainerrthathe experts on git\nextension management and relieves plugin authors, package authors and\npackage-manager authors of this responsibility.\n\nI ask. is that not a very good thing?\n\n>\n> - The \"main command\" (git-atomic, for instance) would be stored in\n> GIT_PREFIX/lib/git-plugins (instead of GIT_PREFIX/lib/git-core, which\n> is where git stores its commands). Git would have to learn to search\n> in GIT_PREFIX/lib/git-plugins in addition to git-core, of course.\n>\n> - Porcelain for git-atomic would go to\n> GIT_PREFIX/lib/git-plugins/git-atomic (or something like this)\n>\n> - The documentation would be stored in GIT_PREFIX/doc/git-atomic\n>\n> - Resources in GIT_PREFIX/share/git-atomic\n>\n> - etc\n>\n> I. e. each plugin stores its stuff in a separate directory, it's just\n> that directory is not a *single* directory but *many* directories,\n> each one inside the proper path under GIT_PREFIX, just like it is for\n> anything you install on a Unix system\n>\n> --\n> Pau Garcia i Quiles\n> http://www.elpauer.org\n> (Due to my workload, I may need 10 days to answer)\n>\n"},{"id":"166631","messageId":"BANLkTikLh5smW1u+V++05JK89EgK-WSzyw@mail.gmail.com","threadId":"27196","inReplyTo":"4DB92F55.5090409@op5.se","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T10:38:09Z","receivedAt":"2011-04-28T10:38:09Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 7:11 PM, Andreas Ericsson wrote:\n> On 04/28/2011 04:15 AM, Jon Seymour wrote:\n>>\n>> * suppose that git-core defined a git install _interface contract_ but\n>> did not define an implementation.\n>>\n>\n> Please. I'm already on my way to a seriously boring sales meeting without\n> having developers throw garbage terms on me. You've done a lot of that in\n> this thread and I for one am confused by them as to what you want to\n> achieve and how you want to achieve it.\n>\n\nI am confused. Is \"interface contract\" a \"garbage term\" for you?\n\nAs I understand the term, it is a good way to enable strong separation\nof concerns and information hiding and these techniques are both\nvaluable tools in the battle against complexity, a battle that I\nunderstand from other posts this in thread you are vitally engaged in.\n\nMy apologies, if terms such as \"separation of concerns\" and\n\"information hiding\" are viscerally offensive to you. I must learn to\ndeploy phrases such as \"horrid\" and \"utterly horrid\" with more panache\nand aplomb.\n\n>> Then, a distribution could install its own implementation of the\n>> git-install plugin into git installations it manages.\n>>\n>> Then a command like:\n>>\n>>      git install gitwork\n>>\n>> would trivially work across all distributions precisely because the\n>> distribution has provided the implementation of the git install\n>> interface contract that git-core has helpfully mandated.\n>>\n>\n> And so we force package maintainers to become git extension developers.\n> Brilliant. They'll love you for it.\n\nThis exactly the wrong way around, but I can understand your mistake\nsince I used this phrase:\n\n- distributions would know how to run git plugin activate and properly\n handle non-zero return codes from same\n\nwhen precision dictates that I should have used the more wordy, but\nmore accurate:\n\n- distributions would know how to invoke plugin installation scripts\nprovided by the plugin author, and these plugin installation scripts\nwould, by virtue of being intimately aware of the public interfaces\n(oops, there is that word again) of git, know how to invoke the git\nplugin command in order to activate their own plugin.\n\nI have explained in my most recent reply to Pau that in the absence of\na plugin management script provided by the git core, any hope of\nplugin conflict management has to be delegated to other parties such\nas the package manager author, the package author or the plugin\nauthor or, alas, to the poor user.\n\nI fail to see why management of plugin conflicts is better handled by\nN authors and M users, rather than a single author of the git-plugin\nscript [ except for the minor detail that the only potential author of\nsuch a script seems to spend all his time writing e-mails instead of\ncutting code ].\n\njon.\n"},{"id":"166632","messageId":"BANLkTikKp9-uFGLavBT0UA5+maV5xiEJZA@mail.gmail.com","threadId":"27196","inReplyTo":"4DB9329E.7000703@op5.se","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T10:56:15Z","receivedAt":"2011-04-28T10:56:15Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 7:25 PM, Andreas Ericsson wrote:\n> On 04/28/2011 04:49 AM, Jon Seymour wrote:\n>> On Thu, Apr 28, 2011 at 12:15 PM, Jon Seymour wrote:\n>>> Then a command like:\n>>>\n>>> git install gitwork\n>>>\n>>> would trivially work across all distributions precisely because the\n>>> distribution has provided the implementation of the git install\n>>> interface contract that git-core has helpfully mandated.\n>>>\n>>\n>> Or better yet, git-core could provide a trivial git install\n>> implementation that selects between different distribution manager\n>> supplied plugins selected according to some heuristic, allowing\n>> several distribution managers to happily manage plugins in the same\n>> git instance.\n>>\n>> I have to ask.\n>>\n>> Is such an architecture really \"absolutely horrid\"? Is it \"crap\"? Really?\n>>\n>\n> Yes, because it forces all distributions to name their extensions\n> the same and it forces all distributions to carry the same extensions.\n\nFalse.\n\nDistributions maintain a N:1 registry of git plugin names to\ndistribution specific package names. This registry would most\nnaturally be maintained by the author who maintains the git package,\nbut of course, such responsibilities could be delegated to others if\nrequired.\n\nDuring installation, the package manage aware \"install\" plugin\nconsults such a registry to determine which packages need to be\ninstalled in order to obtain the requested plugin. It then asks the\npackage manager to install said packages.\n\n> It also makes it impossible to support 3rd party extensions that core\n> git doesn't know about and that aren't already packaged, unless you\n> want the \"git install\" command to have knowledge about all package\n> management systems and *very, very good* heuristics when guessing what\n> a particular extension is called on that system.\n>\n\nAgain false. That is the role of the registry that is maintained by\nsome package author.\n\n> What will happen though is that the distributions will happily ignore\n> that and the \"git install\" command will fail for some extensions on\n> some distributions.\n\nYes, but it can fail in a extremely precise way. In those cases, it\ncould fall back another package manager\nsuch as one that is capable of checking out a git repo and running make install.\n\nI realise that most people could not accomplish such a task without\nwriting vast amounts of spaghetti code, but there you go.\n\n>\n> Besides that, it forces users to install git from their distribution\n> packages so we're hard-shafting the git developers who usually have\n> at least some installations done from source.\n>\n\nNo it doesn't. My suggestion allows deploy by drop-in configuration to\na subdirectory of plugins/ followed by the invocation of a command\nsuch as.\n\n git plugin activate foobar\n\nI realise this may \"hard-shaft\" the git developers who are unable to\ninvoke a git command, but I guess they could also put such a command\nin their make install scripts. Now there's an idea.\n\n> We just went far beyond \"absolutely horrid\" and into the realms of\n> \"steaming pile of abominably manure-like ideas whose inventor should\n> be slapped silly for their own good\".\n>\n\nThanks, I'll add that to my vocabulary of terms that git developers\nuse when they let fly to their emotions for completely unaccountable\nreasons. I'd suggest,. perhaps \"grow up\", but that would strike some\nas rude. So, I won't.\n\n> So let's get back to the basic wish you have here. You want people\n> to be able to easily find, download and install \"git work\" so that it\n> works nicely with man-pages and all.\n>\n\nWhat is so hard about:\n\n app install plugin.\n\nForget git. Forget git work.\n\nWhat is so hard about the concept of an application providing a\nfacility that allows it to request, merely request, the installation\nof a plugin for itself by what ever happens to be the users choice of\npackage manager or distribution.\n\nIs such a concept really, fundamentally flawed?\n\nif so, replace \"git\" with \"linux\", \"app\" with \"apt-get\", \"plugin\" with\n\"git-core\" and explain to me why\n\napt-get install git-core\n\nis such a bad idea.\n\nYes, different levels of abstraction, but the principles are the same.\n\nLike it or not, git is a platform, there is absolutely no reason why\nit can't have sane plugin manager, other than complete lack of\nimagination.\n\n\n> The wiki-page with known extensions and the patch to core git so that\n> \"make install\" can put man-pages in the right directory are the first,\n> simplest and smallest steps that takes us the farthest towards that\n> wish without burdening people you have no control over with more labor.\n> In short; It's both good engineering and polite to implement that and\n> then consider what new possibilities open up and see what people do\n> with those possibilities. You might be surprised.\n\nYep, that's what unix package management was like before people\ninvented the idea of package managers.\n\nHow quaint.\n\njon.\n"},{"id":"166633","messageId":"20110428111154.GA1433@elie","threadId":"27196","inReplyTo":"BANLkTikKp9-uFGLavBT0UA5+maV5xiEJZA@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-04-28T11:11:54Z","receivedAt":"2011-04-28T11:11:54Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Hi,\n\nJon Seymour wrote:\n\n> What is so hard about:\n>\n> app install plugin.\n>\n> Forget git. Forget git work.\n>\n> What is so hard about the concept of\n[...]\n\nIs it so important that the people on this list agree with you\nright away that your proposal is a great idea?\n\nYou asked for comments, so people are giving them. But typically,\nthe procedure might be something like:\n\n1. person describes a problem they are solving, and perhaps a\n proposed solution\n\n2. people on the mailing list try to help out in figuring out the\n parameters of the problem, giving relevant background about the\n tools available, and describing experiences they have had in the\n past that might help in solving it.\n\n3. person reports on how it panned out. If this involved changing\n git or is nicely documented, we might get a patch out of it. If\n so:\n\n4. people on the mailing list review the patch, considering how\n useful it might be for their own nefarious ends, potential\n downsides, and how maintainable it is.\n\n5. at some point, some patches appear that seem to be a good idea,\n and Junio applies them.\n\nAnd so forth. Notice how at no step everyone needs to agree.\n\nEarlier in this thread you mentioned that git needs some basic\nfacilities to make a prototype of a command installer possible.\nBut git already has those facilities. Even if the installed commands\nshould not be on the path, all you need to get a \"git install\"\navailable on early adopters' machines is to put an executable at\n/usr/bin/git-install or ~/bin/git-install.\n\nSo you can show people what they have missing, and once they can't\nlive without it, maybe they'll clamor for its inclusion in git.git\nproper and distro packages. If that is your goal, getting something\nworking and helping interested people to try it out (and adding it\nto https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools\nwhen ready) comes first.\n\nSorry to spend so long on abstractions. Still, hope that helps.\n\nRegards,\nJonathan\n"},{"id":"166634","messageId":"BANLkTi=TEXffPsH3A1tdzFYTszE_Z4U1fw@mail.gmail.com","threadId":"27196","inReplyTo":"20110428111154.GA1433@elie","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-28T11:20:23Z","receivedAt":"2011-04-28T11:20:23Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Thu, Apr 28, 2011 at 9:11 PM, Jonathan Nieder wrote:\n> Hi,\n>\n> Jon Seymour wrote:\n>\n>> What is so  hard about:\n>>\n>>   app install plugin.\n>>\n>> Forget git. Forget git work.\n>>\n>> What is so hard about the concept of\n> [...]\n>\n> Is it so important that the people on this list agree with you\n> right away that your proposal is a great idea?\n>\n> You asked for comments, so people are giving them.  But typically,\n> the procedure might be something like:\n>\n> 1. person describes a problem they are solving, and perhaps a\n>   proposed solution\n>\n> 2. people on the mailing list try to help out in figuring out the\n>   parameters of the problem, giving relevant background about the\n>   tools available, and describing experiences they have had in the\n>   past that might help in solving it.\n>\n> 3. person reports on how it panned out.  If this involved changing\n>   git or is nicely documented, we might get a patch out of it.  If\n>   so:\n>\n> 4. people on the mailing list review the patch, considering how\n>   useful it might be for their own nefarious ends, potential\n>   downsides, and how maintainable it is.\n>\n> 5. at some point, some patches appear that seem to be a good idea,\n>   and Junio applies them.\n>\n> And so forth.  Notice how at no step everyone needs to agree.\n>\n> Earlier in this thread you mentioned that git needs some basic\n> facilities to make a prototype of a command installer possible.\n> But git already has those facilities.  Even if the installed commands\n> should not be on the path, all you need to get a \"git install\"\n> available on early adopters' machines is to put an executable at\n> /usr/bin/git-install or ~/bin/git-install.\n>\n> So you can show people what they have missing, and once they can't\n> live without it, maybe they'll clamor for its inclusion in git.git\n> proper and distro packages.  If that is your goal, getting something\n> working and helping interested people to try it out (and adding it\n> to https://git.wiki.kernel.org/index.php/InterfacesFrontendsAndTools\n> when ready) comes first.\n>\n> Sorry to spend so long on abstractions.  Still, hope that helps.\n>\n> Regards,\n> Jonathan\n>\n\nAgreed. I'll get coding. Thanks for the advice.\n\njon.\n"},{"id":"166655","messageId":"alpine.DEB.2.00.1104280915230.7120@asgard.lang.hm","threadId":"27196","inReplyTo":"BANLkTimyFmujc+Lsd7DMWfJgUzZME+Sveg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"","fromEmail":"david@lang.hm","sentAt":"2011-04-28T16:16:36Z","receivedAt":"2011-04-28T16:16:36Z","isPatch":false,"sender":{"key":"david@lang.hm","avatar":null},"body":"On Thu, 28 Apr 2011, Jon Seymour wrote:\n\n> On Thu, Apr 28, 2011 at 3:07 AM, A Large Angry SCM wrote:\n>>\n>> For a git plugin ecosystem to work, a (relatively) stable API/ABI is\n>> necessary for the plugin authors to code to. Where is your proposal for\n>> that.\n>>\n>\n> To answer your question, the intent is to provide plugins git's\n> command line interface.\n>\n> As has already explained by Junio amongst others, git already provides\n> support for such extensions via its idiom of treating any executable\n> of the form git-{command} found in the PATH.\n>\n> The intention of my proposal is simply to formalise the plugin\n> architecture and provide a degree of plugin management.\n\nstart with documenting (and therefor formalizing) how plugins can work \ntoday. Then propose your change to how they work, what the benifits of \nyour change are, and the code needed to implement your change.\n\nDavid Lang\n\n> Of course, others might think there is a need for ABI plugins, and\n> they are free to propose such extensions, but that is not my intent.\n>\n> jon.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"166704","messageId":"BANLkTikhqx2+JCey_ivP+Q+8X2VYT3hPKw@mail.gmail.com","threadId":"27196","inReplyTo":"alpine.DEB.2.00.1104280915230.7120@asgard.lang.hm","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-04-29T03:35:07Z","receivedAt":"2011-04-29T03:35:07Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":" wrote:\n> On Thu, 28 Apr 2011, Jon Seymour\n> start with documenting (and therefor formalizing) how plugins can work today. Then propose your change to how they work, what the benifits of your change are, and the code needed to implement your change.\n>\n\n\nGood suggestion, thank you,\n\njon\n"},{"id":"167192","messageId":"88795B20-6994-46A5-9710-2ADC84E04695@gmail.com","threadId":"27196","inReplyTo":"BANLkTikKp9-uFGLavBT0UA5+maV5xiEJZA@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2011-05-05T21:41:15Z","receivedAt":"2011-05-05T21:41:15Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Apr 28, 2011, at 3:56 AM, Jon Seymour wrote:\n> What is so hard about:\n> \n> app install plugin.\n> \n> Forget git. Forget git work.\n> \n> What is so hard about the concept of an application providing a\n> facility that allows it to request, merely request, the installation\n> of a plugin for itself by what ever happens to be the users choice of\n> package manager or distribution.\n\nIt's not hard. We simply don't need it. \n\nWhy do I need to activate my \"plugin\"? That seems like a needless feature. If I don't want \"git gui\" I apt-get uninstall git-gui.\n\nI've read this thread and do not understand what problem this is trying to solve. I have personally gotten along just fine writing git applications and deploying them with existing package managers. I've not once ran into any situation where I felt I needed more support from git in order to deploy git commands.\n\nUsers already know about their package manager. Why do we need them to learn about Yet Another system?\n\n\n> Is such a concept really, fundamentally flawed?\n\nYes\n\n> if so, replace \"git\" with \"linux\", \"app\" with \"apt-get\", \"plugin\" with\n> \"git-core\" and explain to me why\n> \n> apt-get install git-core\n> \n> is such a bad idea.\n> \n> Yes, different levels of abstraction, but the principles are the same.\n> \n> Like it or not, git is a platform, there is absolutely no reason why\n> it can't have sane plugin manager, other than complete lack of\n> imagination.\n\nIt doesn't need one. I'm happy with apt, yum, etc. I probably don't understand why I need to learn more, but ignorance is bliss and users like to be blissful.\n\nLet's assume we did have this system for a minute. Now we are worse off because many git apps do not and will never use the new plugin system.\n\nAre we going to one day remove the awesome \"search for git-foo in path\" behavior and break everyone? I think not. In other words, I see little incentive for existing, established git apps to use such a system.\n\nSorry if I seem like a hard-liner, but we should always strive to keep things as simple as possible. I don't see any downsides to the current situation which is why I would resist such a proposal. The upside would have to be pretty significant to convince established git apps to switch.\n-- \n David"},{"id":"167193","messageId":"7vhb986chl.fsf@alter.siamese.dyndns.org","threadId":"27196","inReplyTo":"88795B20-6994-46A5-9710-2ADC84E04695@gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-05T21:53:10Z","receivedAt":"2011-05-05T21:53:10Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"David Aguilar writes:\n\n> On Apr 28, 2011, at 3:56 AM, Jon Seymour wrote:\n> \n>> What is so hard about the concept of an application providing a\n>> facility that allows it to request, merely request, the installation\n>> of a plugin for itself by what ever happens to be the users choice of\n>> package manager or distribution.\n>\n> It's not hard. We simply don't need it. \n>\n> Why do I need to activate my \"plugin\"? That seems like a needless\n> feature. If I don't want \"git gui\" I apt-get uninstall git-gui.\n\nI mostly agree with you that what Jon has wrote so far is overengineering\nto solve a problem that does not exist [*1*].\n\nBut here is one thought.\n\nImagine this \"git gui\" is not \"git gui\" but \"git superadd\" package that\nchanges the behaviour of \"git add\" slightly.\n\n Side note: Of course, for this kind of usage, the \"git potty\" needs to\n be extended to look for things in different places, and also it needs\n to be made easy for the implementation of \"superadd\" to call the\n underlying \"git add\", bypassing itself, when necessary.\n\nYou do not want that new interface, you are old timer and you like the old\nway of doing things like me ;-). But your wife wants to use it. You two\nshare a computer.\n\nDo you or do you not run \"apt-get install git-superadd\"?\n\nOne possible answer may be to run \"apt-get install git-superadd\", and then\nthe users who want \"git add\" to behave in a new way to opt-in to use the\n\"plug-in\". I think that is what Jon is getting at.\n\n\n[Footnote]\n\n*1* I admit that I didn't read all of them carefully, as I was repelled by\nthem as soon as I saw phrases like \"for people who can grok this concept\".\n"},{"id":"167204","messageId":"BANLkTi=+emhzqfiGxGbnJ=bm3oL7SvjhBw@mail.gmail.com","threadId":"27196","inReplyTo":"7vhb986chl.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-05T23:51:17Z","receivedAt":"2011-05-05T23:51:17Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"| Junio: apologies, reply missed list. Edited slightly.\n\nOn Fri, May 6, 2011 at 7:53 AM, Junio C Hamano wrote:\n> David Aguilar writes:\n>\n>> On Apr 28, 2011, at 3:56 AM, Jon Seymour wrote:\n>>\n>>> What is so hard about the concept of an application providing a\n>>> facility that allows it to request, merely request, the installation\n>>> of a plugin for itself by what ever happens to be the users choice of\n>>> package manager or distribution.\n>>\n>> It's not hard. We simply don't need it.\n>>\n>> Why do I need to activate my \"plugin\"? That seems like a needless\n>> feature. If I don't want \"git gui\" I apt-get uninstall git-gui.\n>\n> I mostly agree with you that what Jon has wrote so far is overengineering\n> to solve a problem that does not exist [*1*].\n>\n\nI do accept that the consensus of the list is that any kind of package\nor plugin management is over-engineering.\n\n> But here is one thought.\n>\n> Imagine this \"git gui\" is not \"git gui\" but \"git superadd\" package that\n> changes the behaviour of \"git add\" slightly.\n>\n> Side note: Of course, for this kind of usage, the \"git potty\" needs to\n> be extended to look for things in different places, and also it needs\n> to be made easy for the implementation of \"superadd\" to call the\n> underlying \"git add\", bypassing itself, when necessary.\n>\n> You do not want that new interface, you are old timer and you like the old\n> way of doing things like me ;-). But your wife wants to use it. You two\n> share a computer.\n>\n> Do you or do you not run \"apt-get install git-superadd\"?\n>\n> One possible answer may be to run \"apt-get install git-superadd\", and then\n> the users who want \"git add\" to behave in a new way to opt-in to use the\n> \"plug-in\". I think that is what Jon is getting at.\n>\n\nYes, the basic premise is that an author of a git extension, which\ndepends only on git, should be able to provide an extension in a form\nthat allows others to drop the extension onto a system, knowing only\nthat the system has git installed.\n\nThe extension author should not need to know about how to build an\napt-get, yum, cygwin or brew package or too much about how to install\ninto a git installation that wasn't installed by a distro. Why should\nthey? Their dependency is simply git.\n\nIt would be good if something like:\n\n unzip -d $(git --plugins-dir) foobar.zip\n\ninstalled scripts, info files and man pages into a place where git\nwould find them and then have git foobar start working without any\nadditional effort by the package author or user.\n\nI accept that anything more sophisticated than \"drop and go\" style\ndeployment of extensions (e.g. plugin management) is overkill, given\nthat the current market for git extensions is miniscule. That said, I\nwould like to get the basic extension mechanism right so that if the\n\"market\" for git plugins ever became wildly successful, then at least\nwe could implement more sophisticated plugin management if we wanted\nto.\n\nThis was the point of the other thread: \"RFC: a minimal plugin\narchitecture\" where I tried to elicit feedback about what an minimal\nsolution would look like, sans my more elaborate visions.\n\nhttp://permalink.gmane.org/gmane.comp.version-control.git/172419\n\n>\n> [Footnote]\n>\n> *1* I admit that I didn't read all of them carefully, as I was repelled by\n> them as soon as I saw phrases like \"for people who can grok this concept\".\n\nJunio: at least quote me accurately. I actually wrote:\n\n\"Contributors who grok the concept as I conceive it are welcome to\nsubmit pull requests.\"\n\nI am a little mystified why use of the word \"grok\" in this way, given the\ncircumstances, caused you to be \"repelled\".\n"},{"id":"167212","messageId":"7vbozg4eqw.fsf@alter.siamese.dyndns.org","threadId":"27196","inReplyTo":"BANLkTi=+emhzqfiGxGbnJ=bm3oL7SvjhBw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2011-05-06T04:47:19Z","receivedAt":"2011-05-06T04:47:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jon Seymour writes:\n\n> | Junio: apologies, reply missed list. Edited slightly.\n>\n> On Fri, May 6, 2011 at 7:53 AM, Junio C Hamano wrote:\n>> David Aguilar writes:\n>>\n>>> On Apr 28, 2011, at 3:56 AM, Jon Seymour wrote:\n>>>\n>>>> What is so hard about the concept of an application providing a\n>>>> ...\n>\n> It would be good if something like:\n>\n> unzip -d $(git --plugins-dir) foobar.zip\n>\n> installed scripts, info files and man pages into a place where git\n> would find them and then have git foobar start working without any\n> additional effort by the package author or user.\n\nThat should be doable without any elaborate \"plugin management\". We only\nneed to enhance the git potty and help system to look for things in a set\nof new directories, and have these unzip installation put their stuff\nthere.\n\n>> [Footnote]\n>>\n>> *1* I admit that I didn't read all of them carefully, as I was repelled by\n>> them as soon as I saw phrases like \"for people who can grok this concept\".\n>\n> Junio: at least quote me accurately. I actually wrote:\n>\n> \"Contributors who grok the concept as I conceive it are welcome to\n> submit pull requests.\"\n>\n> I am a little mystified why use of the word \"grok\" in this way, given the\n> circumstances, caused you to be \"repelled\".\n\nWhat repelled me was not any particular word (and that is exactly why I\ndid not even bother to \"quote\") but your general attitude in the\ndiscussion. Your tone throughout the discussion appeared at least to me\nthat you thought anybody who did not agree with you was incapable of\nunderstanding something so obvious and clearly right, and only those who\ncould \"grok\" it deserved to join the discussion. We occasionally have\nseen such people on this list in the past, but luckily not very often.\n\nI am not saying that your thinking should always start from \"I could be\nwrong\". However, I do not think \"What is so hard about the concept ...?\"\nis the question you should be asking others before asking yourself \"Is\nthere a better way I could have explained this idea I want others to agree\nwith? The reason why they are still not on the same page as I am could\nwell be because all of them are morons, but it may be possible that it is\nbecause the way I have explained my idea to them was not optimal. Perhaps\nI did not present the motivation and the background well enough to justify\nthat the problem I am trying to solve is worth solving, before throwing my\nidea on how to solve it\".\n\nAfter all, different people have different needs and expectations. The\ndiscussion on a particular _solution_ can only start after you get people\non board and share the sense of _need_ to solve something common.\n"},{"id":"167220","messageId":"BANLkTi=zrWR0GAm6n1Gs9XDCR6kXtjDW0A@mail.gmail.com","threadId":"27196","inReplyTo":"7vbozg4eqw.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-06T06:20:24Z","receivedAt":"2011-05-06T06:20:24Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Fri, May 6, 2011 at 2:47 PM, Junio C Hamano wrote:\n> Jon Seymour writes:\n>> It would be good if something like:\n>>\n>> unzip -d $(git --plugins-dir) foobar.zip\n>>\n>> installed scripts, info files and man pages into a place where git\n>> would find them and then have git foobar start working without any\n>> additional effort by the package author or user.\n\n> That should be doable without any elaborate \"plugin management\". We only\n> need to enhance the git potty and help system to look for things in a set\n> of new directories, and have these unzip installation put their stuff\n> there.\n\nI do agree - plugin management is superfluous to current requirements.\n\n>>>\n>>> *1* I admit that I didn't read all of them carefully, as I was repelled by\n>>> them as soon as I saw phrases like \"for people who can grok this concept\".\n>>\n>> Junio: at least quote me accurately. I actually wrote:\n>>\n>> \"Contributors who grok the concept as I conceive it are welcome to\n>> submit pull requests.\"\n>>\n>> I am a little mystified why use of the word \"grok\" in this way, given the\n>> circumstances, caused you to be \"repelled\".\n>\n> What repelled me was not any particular word (and that is exactly why I\n> did not even bother to \"quote\") but your general attitude in the\n> discussion.  Your tone throughout the discussion appeared at least to me\n> that you thought anybody who did not agree with you was incapable of\n> understanding something so obvious and clearly right, and only those who\n> could \"grok\" it deserved to join the discussion.  We occasionally have\n> seen such people on this list in the past, but luckily not very often.\n>\n> I am not saying that your thinking should always start from \"I could be\n> wrong\".  However, I do not think \"What is so hard about the concept ...?\"\n> is the question you should be asking others before asking yourself \"Is\n> there a better way I could have explained this idea I want others to agree\n> with?  The reason why they are still not on the same page as I am could\n> well be because all of them are morons, but it may be possible that it is\n> because the way I have explained my idea to them was not optimal.  Perhaps\n> I did not present the motivation and the background well enough to justify\n> that the problem I am trying to solve is worth solving, before throwing my\n> idea on how to solve it\".\n>\n> After all, different people have different needs and expectations.  The\n> discussion on a particular _solution_ can only start after you get people\n> on board and share the sense of _need_ to solve something common.\n>\n\nOk, well thanks for taking the time to explain what you really meant.\n\nI agree that I have come across as arrogant; I reacted badly to what I\nconsidered to be insults being heaped in my direction by some.\nHowever, I did myself and my ideas no favors by treating such\ncriticism with the public disdain that I did.\n\nI also agree that I did a lousy job explaining the concepts let alone\nconvincing others of their merits.\n\nFinally, I agree that it would be more productive for me to be more\nsensitive to what is agreed to be a common need and to try to restrict\nmy proposed solutions to exactly those needs.\n\nI would appreciate any feedback you (or others) have about:\n\n http://permalink.gmane.org/gmane.comp.version-control.git/172419\n\nIn particular, I would be interested in feedback about how to best support:\n\n- multiple extensions - do we want support installing extensions in\ntheir own directories, per Pau's suggestion or simply allow them to\nwrite to a common directory?\n- multiple extension directories - how to support Jonathan's\nrequirement to allow user specific extension directories?\n\nI have some ideas about how to do this which I will propose in a patch\nover the next few weeks, but any input I have now would be useful.\n\nRegards,\n\njon.\n"},{"id":"167223","messageId":"20110506065601.GB13351@elie","threadId":"27196","inReplyTo":"BANLkTi=zrWR0GAm6n1Gs9XDCR6kXtjDW0A@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-06T06:56:01Z","receivedAt":"2011-05-06T06:56:01Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jon Seymour wrote:\n\n> I would appreciate any feedback you (or others) have about:\n>\n> http://permalink.gmane.org/gmane.comp.version-control.git/172419\n>\n> In particular, I would be interested in feedback about how to best support:\n>\n> - multiple extensions - do we want support installing extensions in\n> their own directories, per Pau's suggestion or simply allow them to\n> write to a common directory?\n> - multiple extension directories - how to support Jonathan's\n> requirement to allow user specific extension directories?\n\nWell, let's step back for a moment. What problem are we solving?\nI still don't even know the answer to that!\n\nOnce upon a time, all git commands lived on the $PATH (typically in\n/usr/bin, $HOME/bin, or some similar place) and could even be\ninvoked directly as git-commandname. At some point someone noticed\nthat by running\n\n\tgit-\n\nit was possible to read the list of all git commands. Unfortunately\nthe list was very long, and this seemed like a much worse introduction\nto git than the shorter list shown by \"git --help\".\n\nThere were also some related minor problems --- for example, git was\nputting more pressure than necessary on filesystems and other\nfacilities to keep track of all the files in $bindir, and providing\nthe dashed forms of commands provides a temptation to use them\nexclusively, making features (like aliases) of the git wrapper less\ndiscoverable. But the main thing was the tab completion.\n\nThe fix was to tuck away the individual commands somewhere under\nlibexecdir, outside $PATH.\n\nNow at some point in this discussion I thought you were solving a\nrelated problem. If a person were to install 100 new commands for\ngit, or a single package with 100 commands in it, then\n\n\tgit-\n\nwould be daunting again. So the task becomes to find a place to tuck\naway these new commands without placing them on the $PATH.\n\nBut now I am less sure. The motivating example has less than 10\ncommands; that doesn't seem worth all the fuss at all. Why not just\ninstall the command on the $PATH? \"git help work\" _would_ work on all\nthe systems I have easy access to. For example, if I write:\n\n\tinstall:\n\t\tinstall -m0755 git-work $(prefix)/bin\n\t\tinstall -d -m0755 $(prefix)/share/man/man1\n\t\tgzip -9 git-work.1.gz\n\t\tinstall -m0644 git-work.1.gz $(prefix)/share/man/man1/\n\t\tinstall -d -m0755 $(prefix)/bin\n\nand the user runs\n\n\tmake install\n\tPATH=$HOME/bin:$PATH\n\nthen \"man git-work\" will just work. Similarly, \"git work --help\"\n(which the git wrapper transforms to \"git help work\") would just work.\n\nI see only a few potential problems remaining:\n\n 1. There is no automatically generated documentation page pointing\n to the documentation for all new commands of this kind. So\n I can run \"git help -a\" to learn about installed commands, but\n I cannot run \"man git\" to do so. Likewise for info.\n\n 2. On platforms like Windows that do not use manpages, my \"git work\"\n documentation will not show up with \"git work --help\". For this,\n it would certainly be useful to have a GIT_HTML_PATH environment\n variable (or some similar name) that could be used to point to a\n list of directories with additional documentation. The default\n could be something along the lines of the default library search\n path (but simpler), like:\n\n\t/usr/local/share/git/help:/usr/share/git/help\n\n Users installing new commands under $HOME might want to prepend\n something like\n\n\t$HOME/share/git/help:\n\n or whatever directory names suit their tastes.\n\n Even better might be a way for \"git help\" to ask the command\n where it puts its documentation, so \"git help work\" would\n internally run \"git work --html-path\".\n\n 3. On a machine with multiple installations of git, my new command\n is not tied to any particular installation but shared by all of\n them. This is a feature, not a bug.\n\n 4. My command is visible with git-, as mentioned above.\n\nMy comments about unprivileged users installing new commands were to\nexplain why an alternative solution to (2) that uses a single\ndirectory where \"git help\" always looks would be inadequate. I still\nthink that but luckily there is a large space of possible designs\nwithout that problem; two are mentioned in the description of (2)\nabove.\n\nNow problems 2 and 4 can be solved at the same time by introducing\nsomething like a GIT_PLUGINS_PATH variable that could be shared for\nboth uses. I'm not so convinced that's a good idea (I prefer to see\ndecoupled solutions to independent problems when it's simple to do)\nbut it could very well turn out okay.\n"},{"id":"167224","messageId":"20110506070339.GC13351@elie","threadId":"27196","inReplyTo":"20110506065601.GB13351@elie","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-06T07:03:39Z","receivedAt":"2011-05-06T07:03:39Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jonathan Nieder wrote:\n\n> \tinstall:\n> \t\tinstall -m0755 git-work $(prefix)/bin\n> \t\tinstall -d -m0755 $(prefix)/share/man/man1\n> \t\tgzip -9 git-work.1.gz\n> \t\tinstall -m0644 git-work.1.gz $(prefix)/share/man/man1/\n> \t\tinstall -d -m0755 $(prefix)/bin\n\nI'm sorry; I don't even know what sequence of keystrokes I used to\nmake this upside-down series of commands. The intent was rather\n\n\tinstall: git-work git-work.1.gz\n\t\t: executable\n\t\tinstall -d -m0755 $(prefix)/bin\n\t\tinstall -m0755 git-work $(prefix)/bin\n\t\t: manual page\n\t\tinstall -d -m0755 $(prefix)/share/man/man1\n\t\tinstall -m0644 git-work.1.gz $(prefix)/share/man/man1\n\nSorry for the noise.\n"},{"id":"167248","messageId":"BANLkTimVjZgOJk1ik7fbhQvW21Fo9eZoXg@mail.gmail.com","threadId":"27196","inReplyTo":"20110506065601.GB13351@elie","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-06T14:07:14Z","receivedAt":"2011-05-06T14:07:14Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Fri, May 6, 2011 at 4:56 PM, Jonathan Nieder wrote:\n> Jon Seymour wrote:\n>\n>> I would appreciate any feedback you (or others) have about:\n>>\n>>     http://permalink.gmane.org/gmane.comp.version-control.git/172419\n>>\n>> In particular, I would be interested in feedback about how to best support:\n>>\n>> - multiple extensions - do we want support installing extensions in\n>> their own directories, per Pau's suggestion or simply allow them to\n>> write to a common directory?\n>> - multiple extension directories - how to support Jonathan's\n>> requirement to allow user specific extension directories?\n>\n> Well, let's step back for a moment.  What problem are we solving?\n> I still don't even know the answer to that!\n>\n\nJonathan,\n\nThanks for your detailed reply.\n\nI think the problem we are trying to solve is this: how to make it as\neasy as possible to install, and get operational, an extension to git.\n\nIf git supported the concept of a standard place to put extensions,\nthen it could be as simple as:\n\n unzip -d $(git --plugins-dir) plugin.zip\n\nwith no need to configure or choose a prefix and no need to edit the\nan .profile or .bashrc to permanently add a directory to the PATH.\n\nIf there is no post-installation configuration step, then it becomes\nmuch easier to write an adhoc script that produces a working\nenvironment that has the extension already operational.\n\nThe idea is that the person or distribution who(/which) installed git\nonto the system has already made decisions about where artifacts\nshould go. Neither the user nor the extension author should have to\nsecond guess or reverse engineer these decisions. Given that git has\nbeen installed in X, then let's use convention to say that extensions\ncan install in X/lib/git-plugins/ (say) and then have git able to use\nthose extensions immediately with no additional configuration step\nbecause this directory is already (effectively) in the PATH.\n\nTo the extent that a configuration step is necessary, post install, it\nwould be good if the configuration was limited to facilities that are\navailable in every git installation (e.g. git config --global).\n\njon.\n"},{"id":"167249","messageId":"20110506141719.GA2991@elie","threadId":"27196","inReplyTo":"BANLkTimVjZgOJk1ik7fbhQvW21Fo9eZoXg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-06T14:17:19Z","receivedAt":"2011-05-06T14:17:19Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jon Seymour wrote:\n\n> If git supported the concept of a standard place to put extensions,\n> then it could be as simple as:\n>\n> unzip -d $(git --plugins-dir) plugin.zip\n>\n> with no need to configure or choose a prefix and no need to edit the\n> an .profile or .bashrc to permanently add a directory to the PATH.\n\nWhy not use \"/usr/local\" in place of \"git --plugins-dir\"? (I can\nthink of one answer --- namely root privileges --- but it would apply\nto any system with one standard place to put extensions.)\n"},{"id":"167251","messageId":"BANLkTikW2u2W=Hpw2G4VJf_h88x4_7x_=Q@mail.gmail.com","threadId":"27196","inReplyTo":"20110506141719.GA2991@elie","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-06T14:29:58Z","receivedAt":"2011-05-06T14:29:58Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Sat, May 7, 2011 at 12:17 AM, Jonathan Nieder wrote:\n> Jon Seymour wrote:\n>\n>> If git supported the concept of a standard place to put extensions,\n>> then it could be as simple as:\n>>\n>>     unzip -d $(git --plugins-dir) plugin.zip\n>>\n>> with no need to configure or choose a prefix and no need to edit the\n>> an .profile or .bashrc to permanently add a directory to the PATH.\n>\n> Why not use \"/usr/local\" in place of \"git --plugins-dir\"?  (I can\n> think of one answer --- namely root privileges --- but it would apply\n> to any system with one standard place to put extensions.)\n>\n\nPartly because that is second guessing &/or reverse engineering the\ndistribution's decisions and\nit won't work for a Windows install where there is no /usr/local\n\nNot that I currently, have a need, but Junio did mention the case\nwhere someone wants to enhance an existing git command with a wrapper\nof some kind. This could be done more precisely if git itself\ncontrolled the relative order of the path components than if one\nrelied on /usr/local being in a particular place in the path.\n\n\njon.\n"},{"id":"167253","messageId":"20110506145036.GB2991@elie","threadId":"27196","inReplyTo":"BANLkTikW2u2W=Hpw2G4VJf_h88x4_7x_=Q@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-06T14:50:37Z","receivedAt":"2011-05-06T14:50:37Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jon Seymour wrote:\n\n> Partly because that is second guessing &/or reverse engineering the\n> distribution's decisions and\n\nWell, no --- that's what /usr/local is _for_:\nhttp://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY\n\n> it won't work for a Windows install where there is no /usr/local\n\nThat's true. I believe command-line users on Windows who install by\nunzipping to a directory are used to having to set a PATH for\nthemselves. Perhaps it would be convenient for git to learn to add a\nspecific standard directory to its private PATH as a Windows-specific\nextension, though.\n\nIf your goal is to make installing new commands for git easier than\ninstalling native apps --- why? It seems backwards. Consider that\nthe end result ought to be easy not only for the app developer but for\nthe end user, and if every program with the ability to call other\nprograms sets up its own better replacement for standard operating\nsystem facilities, that will make for a complicated system to\nadminister indeed. So with that in mind, it might be simpler to take\nadvantage of existing project that simplifies installation of native\napps, like .\n\nThe development environment for git on Windows (mysgit) does provide a\ndirectory hierarchy complete with /usr et al, so people using that\nvery well might want to install to /usr/local. Likewise with Cygwin.\n\n> Not that I currently, have a need, but Junio did mention the case\n> where someone wants to enhance an existing git command with a wrapper\n> of some kind.\n\nFor reasons you've hinted at before, Git deliberately does not allow\nthat (similarly, it does not allow git aliases to override existing\ncommands). $GIT_EXEC_PATH comes first on the PATH that git uses\ninternally. That's a feature, not a bug, imho.\n"},{"id":"167265","messageId":"20110506172334.GB16576@sigill.intra.peff.net","threadId":"27196","inReplyTo":"BANLkTimVjZgOJk1ik7fbhQvW21Fo9eZoXg@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-06T17:23:34Z","receivedAt":"2011-05-06T17:23:34Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, May 07, 2011 at 12:07:14AM +1000, Jon Seymour wrote:\n\n> I think the problem we are trying to solve is this: how to make it as\n> easy as possible to install, and get operational, an extension to git.\n> \n> If git supported the concept of a standard place to put extensions,\n> then it could be as simple as:\n> \n> unzip -d $(git --plugins-dir) plugin.zip\n> \n> with no need to configure or choose a prefix and no need to edit the\n> an .profile or .bashrc to permanently add a directory to the PATH.\n\nThis seems slightly backwards to me. You are asking git \"where should\nplugins go?\" and then putting them there. But that leaves no room for\nplugins going in _multiple_ places. IOW, the usual hierarchy of:\n\n 1. distribution-packaged extensions (in /usr/share/git/plugins)\n\n 2. local system-wide extensions (in /usr/local/share/git/plugins)\n\n 3. per-user extensions (in $HOME/.gitplugins)\n\nIt seems like we should not be asking git, but _telling_ git about where\nour plugins are. I understand that you don't want the user to have to do\nany additional steps, and I think that is a reasonable goal. But can't\nthat be easily accomplished by:\n\n 1. The git wrapper learns to look in a set of plugin paths, something\n like:\n\n foreach path in (list of plugin paths)\n foreach plugin in \"path/*\"\n add plugin/bin to PATH\n add plugin/man to MANPATH\n\n 2. At compile time, we give some stock system directories like\n /usr/share/git/plugins and /usr/local/share/git/plugins.\n Distribution packages of git override as appropriate for the target\n system.\n\n 3. We always check $HOME/.gitplugins by default.\n\n 4. Users can set GIT_PLUGIN_PATH in the environment if they want to do\n something fancy (they can also always just set PATH and MANPATH\n manually if they want, too).\n\nThis is how many systems already work. For example, look at how vim\nhandles plugins.\n\nDistro-packaged extensions obviously know where to go (the packager\nknows their distro's rules). People with personal extensions don't have\nto know anything special; their packages go in $HOME/.gitplugins.\n\nIn general I would expect /usr/local/share/git/plugins to be pretty\nstandard, and not needing of being repeated for admins who want to\ninstall something system-wide. But if you want to be really thorough,\nthen your \"git --plugins-dir\" should probably report the \"system-wide\nbut not distro\" directory for that (but I would call it something like\n\"git --system-plugins-dir\" or something to make it more clear).\n\n-Peff\n"},{"id":"167312","messageId":"BANLkTi=DreFEHWf0Ndd-3cAiaCtFgZHe2A@mail.gmail.com","threadId":"27196","inReplyTo":"20110506172334.GB16576@sigill.intra.peff.net","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"John Szakmeister","fromEmail":"john@szakmeister.net","sentAt":"2011-05-07T08:24:58Z","receivedAt":"2011-05-07T08:24:58Z","isPatch":false,"sender":{"key":"john@szakmeister.net","avatar":"https://avatars.githubusercontent.com/u/448087?v=4"},"body":"On Fri, May 6, 2011 at 1:23 PM, Jeff King wrote:\n> On Sat, May 07, 2011 at 12:07:14AM +1000, Jon Seymour wrote:\n>\n>> I think the problem we are trying to solve is this: how to make it as\n>> easy as possible to install, and get operational, an extension to git.\n>>\n>> If git supported the concept of a standard place to put extensions,\n>> then it could be as simple as:\n>>\n>>     unzip -d $(git --plugins-dir) plugin.zip\n>>\n>> with no need to configure or choose a prefix and no need to edit the\n>> an .profile or .bashrc to permanently add a directory to the PATH.\n>\n> This seems slightly backwards to me. You are asking git \"where should\n> plugins go?\" and then putting them there. But that leaves no room for\n> plugins going in _multiple_ places. IOW, the usual hierarchy of:\n>\n>  1. distribution-packaged extensions (in /usr/share/git/plugins)\n>\n>  2. local system-wide extensions (in /usr/local/share/git/plugins)\n>\n>  3. per-user extensions (in $HOME/.gitplugins)\n\nExactly! I'd really like to see (3) and stop cluttering up my\n~/.local/bin folder with wrapper scripts.\n\n-John\n"},{"id":"167342","messageId":"BANLkTimdS7vs71vEVTxutvyp3rC4KxPjMA@mail.gmail.com","threadId":"27196","inReplyTo":"20110506145036.GB2991@elie","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-08T04:28:39Z","receivedAt":"2011-05-08T04:28:39Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Sat, May 7, 2011 at 12:50 AM, Jonathan Nieder wrote:\n> Jon Seymour wrote:\n>\n>> Partly because that is second guessing &/or reverse engineering the\n>> distribution's decisions and\n>\n> Well, no --- that's what /usr/local is _for_:\n> http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY\n>\n\nSorry, what I really meant to say is that /usr/local/bin is not always\nin a user's path *** . Whether it is or not depends in part on which\ndistribution manager you use on MAC OSX [ brew does user /usr/local,\nbut MAC Ports uses /opt/local ].\n\n*** I may be wrong about this - /usr/local/bin is actually in my MAC's\npath, but I think I had to edit /etc/profile to get it there.\n\nThat said, once git is installed, there is usually a directory like\n/usr/local or /opt/local that could be used as the default prefix to\ntarget the installation of a plugin.\n\nPerhaps there is a case for a git --prefix to provide that hint?\n\n>> it won't work for a Windows install where there is no /usr/local\n>\n> That's true.  I believe command-line users on Windows who install by\n> unzipping to a directory are used to having to set a PATH for\n> themselves.  Perhaps it would be convenient for git to learn to add a\n> specific standard directory to its private PATH as a Windows-specific\n> extension, though.\n>\n> If your goal is to make installing new commands for git easier than\n> installing native apps --- why?  It seems backwards.  Consider that\n> the end result ought to be easy not only for the app developer but for\n> the end user, and if every program with the ability to call other\n> programs sets up its own better replacement for standard operating\n> system facilities, that will make for a complicated system to\n> administer indeed.  So with that in mind, it might be simpler to take\n> advantage of existing project that simplifies installation of native\n> apps, like .\n>\n\nI will have a look at zero-install, though quick inspection seems to\nindicate that it is best for running standalone apps and not\nnecessarily great for the task at hand here.\n\nThe idea isn't to replace standard operating system facilities for\napplication installation. The idea is to provide a uniform interface\nfor accomplishing the rather limited task of extending git that can\nwork the same way, irrespective of platform, irrespective of file\nsystem layouts, irrespective of assumptions about which directories\nare already in the user's paths.\n\nOne answer is for each extension author to invent their own way to\nproduce packages that can be installed in a cross-platform way across\nmultiple platforms but this seems like an unnecessary duplication of\neffort compared to a possible alternative.\n\nIf at the end of the day, we say make and install are the way to do\nit, then fine. However, this makes the dependencies for a successful\ninstall strictly greater than the existence of git and a POSIX shell\nwhich we can assume if git is already installed.\n\njon.\n"},{"id":"167343","messageId":"BANLkTikDVBgOqd1U=qSL99U3K8EtLVTxtw@mail.gmail.com","threadId":"27196","inReplyTo":"20110506172334.GB16576@sigill.intra.peff.net","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-08T04:44:54Z","receivedAt":"2011-05-08T04:44:54Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Sat, May 7, 2011 at 3:23 AM, Jeff King wrote:\n> On Sat, May 07, 2011 at 12:07:14AM +1000, Jon Seymour wrote:\n>\n>> I think the problem we are trying to solve is this: how to make it as\n>> easy as possible to install, and get operational, an extension to git.\n>>\n>> If git supported the concept of a standard place to put extensions,\n>> then it could be as simple as:\n>>\n>>     unzip -d $(git --plugins-dir) plugin.zip\n>>\n>> with no need to configure or choose a prefix and no need to edit the\n>> an .profile or .bashrc to permanently add a directory to the PATH.\n>\n> This seems slightly backwards to me. You are asking git \"where should\n> plugins go?\" and then putting them there. But that leaves no room for\n> plugins going in _multiple_ places. IOW, the usual hierarchy of:\n>\n>  1. distribution-packaged extensions (in /usr/share/git/plugins)\n>\n>  2. local system-wide extensions (in /usr/local/share/git/plugins)\n>\n>  3. per-user extensions (in $HOME/.gitplugins)\n>\n\nActually, that was part of my RFC - how to let git find places where\nplugins may be installed.\n\nYour suggestions seem good to me.\n\n> It seems like we should not be asking git, but _telling_ git about where\n> our plugins are. I understand that you don't want the user to have to do\n> any additional steps, and I think that is a reasonable goal. But can't\n> that be easily accomplished by:\n>\n>  1. The git wrapper learns to look in a set of plugin paths, something\n>     like:\n>\n>       foreach path in (list of plugin paths)\n>         foreach plugin in \"path/*\"\n>           add plugin/bin to PATH\n>           add plugin/man to MANPATH\n>\n>  2. At compile time, we give some stock system directories like\n>     /usr/share/git/plugins and /usr/local/share/git/plugins.\n>     Distribution packages of git override as appropriate for the target\n>     system.\n>\n>  3. We always check $HOME/.gitplugins by default.\n>\n\nAll seems reasonable, assuming that there is a consensus that we need\nto do something other than recommend installation into /usr/local (or\nthe platform equivalent) and I am not sure that is a given at this\npoint.\n\n>  4. Users can set GIT_PLUGIN_PATH in the environment if they want to do\n>     something fancy (they can also always just set PATH and MANPATH\n>     manually if they want, too).\n>\n\nIf the need for multiple plugin directories were accepted, then I\nwonder if there might not be some advantages for the configuration of\nthis path being in git configuration rather than an environment\nvariable? Again, assuming only git, this would provide installation\nhelpers with a standard way to make git aware of such directories that\ndoes not depend on the particulars of the platform on which git is\ninstalled.\n\n> This is how many systems already work. For example, look at how vim\n> handles plugins.\n>\n> Distro-packaged extensions obviously know where to go (the packager\n> knows their distro's rules). People with personal extensions don't have\n> to know anything special; their packages go in $HOME/.gitplugins.\n>\n> In general I would expect /usr/local/share/git/plugins to be pretty\n> standard, and not needing of being repeated for admins who want to\n> install something system-wide. But if you want to be really thorough,\n> then your \"git --plugins-dir\" should probably report the \"system-wide\n> but not distro\" directory for that (but I would call it something like\n> \"git --system-plugins-dir\" or something to make it more clear).\n>\n\nI think that your suggestion of --system-plugins-dir is a good one for\nthe reasons you suggest.\n\n> -Peff\n>\n"},{"id":"167344","messageId":"20110508064902.GA12868@elie","threadId":"27196","inReplyTo":"BANLkTimdS7vs71vEVTxutvyp3rC4KxPjMA@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jonathan Nieder","fromEmail":"jrnieder@gmail.com","sentAt":"2011-05-08T06:49:02Z","receivedAt":"2011-05-08T06:49:02Z","isPatch":false,"sender":{"key":"jrnieder@gmail.com","avatar":"https://avatars.githubusercontent.com/u/281595?v=4"},"body":"Jon Seymour wrote:\n\n> The idea isn't to replace standard operating system facilities for\n> application installation. The idea is to provide a uniform interface\n> for accomplishing the rather limited task of extending git that can\n> work the same way, irrespective of platform, irrespective of file\n> system layouts, irrespective of assumptions about which directories\n> are already in the user's paths.\n[...]\n> If at the end of the day, we say make and install are the way to do\n> it, then fine. However, this makes the dependencies for a successful\n> install strictly greater than the existence of git and a POSIX shell\n> which we can assume if git is already installed.\n\nThanks for explaining, and sorry to have given so much grief by not\nunderstanding.\n\nIf this whole conversation were about how to add a new menu item to\ngit gui, I would have understood completely. Having to figure out how\nto get something in a directory listed in PATH would be undue\ncomplication.\n\nAfter going in circles a few times, I think you're saying there are\nalso some people using git on the command line for whom \"make\nprefix= install\" won't cut it. With such a person in mind,\nwhat you're trying to do makes sense --- and why not do it, when it\nwill bring some other benefits as a side-effect, like the ability to\nadd new commands without them showing up in git- tab completion?\nSo I'll be quiet now.\n"},{"id":"167348","messageId":"BANLkTimEMkpm9HFGmdvK4-3Pp=AKbXNRrw@mail.gmail.com","threadId":"27196","inReplyTo":"20110508064902.GA12868@elie","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-08T07:42:23Z","receivedAt":"2011-05-08T07:42:23Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Sun, May 8, 2011 at 4:49 PM, Jonathan Nieder wrote:\n> Jon Seymour wrote:\n>\n>> The idea isn't to replace standard operating system facilities for\n>> application installation. The idea is to provide a uniform interface\n>> for accomplishing the rather limited task of extending git that can\n>> work the same way, irrespective of platform, irrespective of file\n>> system layouts, irrespective of assumptions about which directories\n>> are already in the user's paths.\n> [...]\n>> If at the end of the day, we say make and install are the way to do\n>> it, then fine. However, this makes the dependencies for a successful\n>> install strictly greater than the existence of git and a POSIX shell\n>> which we can assume if git is already installed.\n>\n> Thanks for explaining, and sorry to have given so much grief by not\n> understanding.\n>\n> If this whole conversation were about how to add a new menu item to\n> git gui, I would have understood completely.  Having to figure out how\n> to get something in a directory listed in PATH would be undue\n> complication.\n>\n> After going in circles a few times, I think you're saying there are\n> also some people using git on the command line for whom \"make\n> prefix= install\" won't cut it.  With such a person in mind,\n> what you're trying to do makes sense --- and why not do it, when it\n> will bring some other benefits as a side-effect, like the ability to\n> add new commands without them showing up in git- tab completion?\n> So I'll be quiet now.\n>\n\nAdmittedly, I think there might be concrete advantages in making at\nhard as possible for such users to get anywhere near a git command\nline, but hey, I work in an environment where ClearCase looks like a\nreasonable option to some people :-)\n\nYour point about support for extension supplied HTML is an interesting\none, that I don't think I have an answer for other than an\ninstallation script that is aware of git --html-path. The reason is,\nyou want links to descriptions of core git commands to just work in\nsuch html, and the only way you can get that to happen reliably is to\ninstall in some directory that is strictly relative to the location\nthat git's own HTML is stored in.\n\nSo, in the end, I think I would be happy with a solution like:\n\n git --system-extensions-prefix\n\nwhich answers the recommended prefix for the installation of\nextensions. This might default git's own prefix, but may be configured\ndifferently by distribution or builder preference. If we did allow it\nto be different to the git prefix, then I think the git runtime would\nneed to be extended to allow $(git --system-plugins-prefix)/bin to\nappear in the path, and then use the existing gt help mechanisms to\nfind the\nman pages.\n\nWould a patch along these lines be acceptable, do you think?\n\njon seymour.\n"},{"id":"167425","messageId":"BANLkTinhN0=2NETtOjG_yvubHiZagGB0Wg@mail.gmail.com","threadId":"27196","inReplyTo":"20110506065601.GB13351@elie","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-08T13:13:35Z","receivedAt":"2011-05-08T13:13:35Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Fri, May 6, 2011 at 4:56 PM, Jonathan Nieder wrote:\n>\n> But now I am less sure.  The motivating example has less than 10\n> commands; that doesn't seem worth all the fuss at all.  Why not just\n> install the command on the $PATH?  \"git help work\" _would_ work on all\n> the systems I have easy access to.  For example, if I write:\n>\n\nAn aspect of the motivational example that I would welcome your\nfeedback on is this.\n\ngit-work is an example of an extension that depends on 3 other\nextensions (git-base, git-atomic and git-test).\n\nSimilarly:\n\n git-base depends on git-test.\n git-atomic depends on git-test\n\nIt seems that if I am to represent these dependencies, I need to\ncreate 4 * N packages, where N is the number of packaging systems I\nwant to support.\n\nIt is unclear how I make:\n\n make install prefix=/usr/local\n\nwork unless the 3 other dependencies have been installed first. If I\nneed to explain that these 3 other dependencies need to be installed,\nthen my installation instructions have just become longer.\n\nThis seems a shame, since each extension has a dependency only on\nother git extensions and git itself. Yet, to provide a workable\ninstallation from source option for my users, I need to either get\nthem to fetch and build all 4 packages from source, or I need to build\npackages for N different distribution managers.\n\n[ FWIW: I recognise that my current proposals for a simple git\n--system-extensions-dir don't make this problem any easier to solve,\nbut I wanted to use the example to demonstrate why a simple make\ninstall script isn't the silver bullet to every installation scenario\n].\n\njon.\n"},{"id":"167458","messageId":"buozkmw5w3j.fsf@dhlpc061.dev.necel.com","threadId":"27196","inReplyTo":"7vhb986chl.fsf@alter.siamese.dyndns.org","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Miles Bader","fromEmail":"miles@gnu.org","sentAt":"2011-05-09T04:36:16Z","receivedAt":"2011-05-09T04:36:16Z","isPatch":false,"sender":{"key":"miles@gnu.org","avatar":"https://gravatar.com/avatar/01069b69593af7bff28e2f97afeb3644ae6fe2f5f56cb3a8cf34c5fb8c36efe5?d=mp&s=160"},"body":"Junio C Hamano writes:\n> Do you or do you not run \"apt-get install git-superadd\"?\n>\n> One possible answer may be to run \"apt-get install git-superadd\", and then\n> the users who want \"git add\" to behave in a new way to opt-in to use the\n> \"plug-in\". I think that is what Jon is getting at.\n\nIf aliases could override built-in command names, it'd be easy enough\n(\"alias add=superadd\") ... [with some feature to allow suppressing the\nalias to prevent recursion, e.g. an environment variable or something.]\n\n-Miles\n\n-- \nJustice, n. A commodity which in a more or less adulterated condition the\nState sells to the citizen as a reward for his allegiance, taxes and personal\nservice.\n"},{"id":"167466","messageId":"20110509073535.GA5657@sigill.intra.peff.net","threadId":"27196","inReplyTo":"BANLkTikDVBgOqd1U=qSL99U3K8EtLVTxtw@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T07:35:35Z","receivedAt":"2011-05-09T07:35:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, May 08, 2011 at 02:44:54PM +1000, Jon Seymour wrote:\n\n> >  4. Users can set GIT_PLUGIN_PATH in the environment if they want to do\n> >     something fancy (they can also always just set PATH and MANPATH\n> >     manually if they want, too).\n> \n> If the need for multiple plugin directories were accepted, then I\n> wonder if there might not be some advantages for the configuration of\n> this path being in git configuration rather than an environment\n> variable?\n\nI think in general most users would not need to set this (since after\nall, the point of your proposal is to avoid such tweaks), so it may not\nbe worth troubling about. But it is much simpler to tell users to run:\n\n git config core.pluginpath /path/to/wherever\n\nthan trying to figure out whether they need to use bashrc, cshrc,\nwhatever Windows uses, etc.\n\n-Peff\n"},{"id":"167467","messageId":"BANLkTi=tfxPN=WLmfn=d+jrHV3U-Rp8T=A@mail.gmail.com","threadId":"27196","inReplyTo":"20110509073535.GA5657@sigill.intra.peff.net","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-09T07:49:27Z","receivedAt":"2011-05-09T07:49:27Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Mon, May 9, 2011 at 5:35 PM, Jeff King wrote:\n> On Sun, May 08, 2011 at 02:44:54PM +1000, Jon Seymour wrote:\n>\n>> >  4. Users can set GIT_PLUGIN_PATH in the environment if they want to do\n>> >     something fancy (they can also always just set PATH and MANPATH\n>> >     manually if they want, too).\n>>\n>> If the need for multiple plugin directories were accepted, then I\n>> wonder if there might not be some advantages for the configuration of\n>> this path being in git configuration rather than an environment\n>> variable?\n>\n> I think in general most users would not need to set this (since after\n> all, the point of your proposal is to avoid such tweaks), so it may not\n> be worth troubling about. But it is much simpler to tell users to run:\n>\n>  git config core.pluginpath /path/to/wherever\n>\n> than trying to figure out whether they need to use bashrc, cshrc,\n> whatever Windows uses, etc.\n\nYep, that was part of the motivation for the suggestion - something\nthat works consistently, assuming only a working git installation.\n\nPer one of my other notes, my initial inclination is to provide a\npatch that implements support for\n\n git --system-extensions-dir\n\nwhich would:\n - provide the caller with location that extensions could be\ninstalled in (assuming the caller can acquire write privileges)\n - provide a guarantee that $(git --system-extensions-dir)/bin will\nbe on the path set up by the git wrapper and $(git\n--system-extensions-dir)/man will be in the MANPATH searched by git\nhelp\n\nExtensions could then use this information, together with git\n--html-path to install themselves into these places using whatever\nmechanism seems appropriate (either a POSIX shell script or a\nmake/install script).\n\nThe default value of git --system-extensions-dir could be supplied\nduring the build and might naturally default to the build prefix, but\ndistributions and other builders could specify an alternative.\n\nAn enhancement to this would then allow core.system-extensions-dir to\noverride the compiled in version.\n\nAnything wrong with this so far?\n\njon\n"},{"id":"167472","messageId":"20110509081219.GB6205@sigill.intra.peff.net","threadId":"27196","inReplyTo":"BANLkTi=tfxPN=WLmfn=d+jrHV3U-Rp8T=A@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T08:12:19Z","receivedAt":"2011-05-09T08:12:19Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 05:49:27PM +1000, Jon Seymour wrote:\n\n> Yep, that was part of the motivation for the suggestion - something\n> that works consistently, assuming only a working git installation.\n> \n> Per one of my other notes, my initial inclination is to provide a\n> patch that implements support for\n> \n> git --system-extensions-dir\n> \n> which would:\n> - provide the caller with location that extensions could be\n> installed in (assuming the caller can acquire write privileges)\n> - provide a guarantee that $(git --system-extensions-dir)/bin will\n> be on the path set up by the git wrapper and $(git\n> --system-extensions-dir)/man will be in the MANPATH searched by git\n> help\n> \n> Extensions could then use this information, together with git\n> --html-path to install themselves into these places using whatever\n> mechanism seems appropriate (either a POSIX shell script or a\n> make/install script).\n\nBut is the system extension dir always the right place to do so? If I'm\nnot root, then that probably won't be writable (or even if I am, I may\nwant to install the extension only for the root user).\n\nIf your proposal is for the user to decide on one of:\n\n unzip -d \"$(git --system-extension-dir)\" git-foo.zip\n\nor\n\n unzip -d \"$HOME/.gitplugins\" git-foo.zip\n\nthen they can make that decision. But if you're proposing that the\nextension-writer distribute a script, then it's more complicated. They\nwould probably need to provide a \"--user\" versus \"--system\" option.\n\nIt would also be tempting to write something like:\n\n install_dir() {\n if test \"`id -u`\" = \"0\"; then\n git --system-extension-dir\n else\n echo $HOME/.gitplugins\n fi\n }\n\nbut that is:\n\n 1. Not portable.\n\n 2. Does not allow for user-only installation by root.\n\nBut all of this is a packaging best-practices issue, not an issue of\nwhat git needs to do to support it (you _could_ address the portability\nissue by having \"git --preferred-extension-path\" that did the\nappropriate platform-specific UID check, but that still doesn't address\nthe second point).\n\n-Peff\n"},{"id":"167477","messageId":"BANLkTimKRo_36Ce2aFWWXdM1a+EgQ-u77Q@mail.gmail.com","threadId":"27196","inReplyTo":"20110509081219.GB6205@sigill.intra.peff.net","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-09T08:45:56Z","receivedAt":"2011-05-09T08:45:56Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Mon, May 9, 2011 at 6:12 PM, Jeff King wrote:\n> On Mon, May 09, 2011 at 05:49:27PM +1000, Jon Seymour wrote:\n>\n>> Yep, that was part of the motivation for the suggestion - something\n>> that works consistently, assuming only a working git installation.\n>>\n>> Per one of my other notes, my initial inclination is to provide a\n>> patch that implements support for\n>>\n>>      git --system-extensions-dir\n>>\n>> which would:\n>>    - provide the caller with location that extensions could be\n>> installed in (assuming the caller can acquire write privileges)\n>>    - provide a guarantee that $(git --system-extensions-dir)/bin will\n>> be on the path set up by the git wrapper and $(git\n>> --system-extensions-dir)/man will be in the MANPATH searched by git\n>> help\n>>\n>> Extensions could then use this information, together with git\n>> --html-path to install themselves into these places using whatever\n>> mechanism seems appropriate (either a POSIX shell script or a\n>> make/install script).\n>\n> But is the system extension dir always the right place to do so? If I'm\n> not root, then that probably won't be writable (or even if I am, I may\n> want to install the extension only for the root user).\n>\n> If your proposal is for the user to decide on one of:\n>\n>  unzip -d \"$(git --system-extension-dir)\" git-foo.zip\n>\n> or\n>\n>  unzip -d \"$HOME/.gitplugins\" git-foo.zip\n\n>\n> then they can make that decision. But if you're proposing that the\n> extension-writer distribute a script, then it's more complicated. They\n> would probably need to provide a \"--user\" versus \"--system\" option.\n>\n\nI am starting to think that deploy-via-zip/tar is unworkable for the\ncase where the extension wants to supply html, since I think an\nattempt has to be made to deploy HTML in the path reported by git\n--html-path for reasons of HTML linkability from extension back to\nthe pages from git-core.\n\nNow, this might not always work, and the install script can either\nfail (to be re-run under sudo at users discretion) or degrade\ngracefully (install what it can, and warn).\n\n> It would also be tempting to write something like:\n>\n>  install_dir() {\n>    if test \"`id -u`\" = \"0\"; then\n>      git --system-extension-dir\n>    else\n>      echo $HOME/.gitplugins\n>    fi\n>  }\n>\n> but that is:\n>\n>  1. Not portable.\n>\n>  2. Does not allow for user-only installation by root.\n>\n> But all of this is a packaging best-practices issue, not an issue of\n> what git needs to do to support it (you _could_ address the portability\n> issue by having \"git --preferred-extension-path\" that did the\n> appropriate platform-specific UID check, but that still doesn't address\n> the second point).\n\nSo, suppose we call it --preferred-extension-path*, then if the user\n(root or otherwise) defines\n\n git config core.preferrred-extension-path ${HOME}/.gitplugins\n\nthen they get to choose where the installer next run will install extensions.\n\nAlso, this would only be a default - installation scripts could have a\nmechanism to specify an override on the command line. Of course, if\nthey supply the override and it is not consistent with\n--preferred-extensions-path/core.preferred-extensions-path then they\nneed to take steps to install that the bin directory is in the PATH,\nbut that's a decision they take themselves as an alternative to\nacquiring the privileges required to modify the directory reported by\ngit --preferred-extensions-path\n\nThe idea is for core to provide extension installers with just enough\ninformation that their installs will work and be discoverable by the\ncore and enough control for distributions to determine the preferred\nlocation for such extensions.\n\n* I would prefer --preferred-extension-dir rather than\n--preferred-extension-path, since I think this name should specify a\nsingle directory and not a list (otherwise the choice of destination\nwould be ambigiuous). I realise this creates an inconsistency with\n--html-path and if consistency is preferred (or I have misinterpreted\nwhat path normally means), I am happy to use\n--preferred-extension-path.\n\njon.\n"},{"id":"167483","messageId":"20110509104446.GB9060@sigill.intra.peff.net","threadId":"27196","inReplyTo":"BANLkTimKRo_36Ce2aFWWXdM1a+EgQ-u77Q@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T10:44:47Z","receivedAt":"2011-05-09T10:44:47Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 06:45:56PM +1000, Jon Seymour wrote:\n\n> I am starting to think that deploy-via-zip/tar is unworkable for the\n> case where the extension wants to supply html, since I think an\n> attempt has to be made to deploy HTML in the path reported by git\n> --html-path for reasons of HTML linkability from extension back to\n> the pages from git-core.\n\nYeah, I don't see a way around that without post-processing the HTML\nlinks at install time (or creating a symlink farm with all of the HTML\npages).\n\n> So, suppose we call it --preferred-extension-path*, then if the user\n> (root or otherwise) defines\n> \n> git config core.preferrred-extension-path ${HOME}/.gitplugins\n> \n> then they get to choose where the installer next run will install extensions.\n\nI thought about suggesting that, but a config option didn't seem a good\nfit to me. The decision of where to put a package seems more likely to\nbe related to which _package_ it is, than which user you are. So a\ncommand-line option would make more sense. And even if you have a config\noption, you would sitll need a command-line one to override, so it's not\nlike you are reducing the amount of code or complexity.\n\nWhich again makes it not a git issue at all, but an issue for\npackage-writers who want to provide a script. It's their job to interact\nwith the user and find out where the user wants to put things (i.e.,\npersonal or system directories).\n\nI don't really see any need for git's role in this to be more than:\n\n 1. Check a set list of directories for extra paths to add to PATH and\n MANPATH.\n\n 2. Tell the packager's script what that set list is, so they can be\n sure to put their files in the right spot.\n\n-Peff\n"},{"id":"167485","messageId":"BANLkTikUjGLBH6_ze7EvRfoKb9h-RREmuA@mail.gmail.com","threadId":"27196","inReplyTo":"20110509104446.GB9060@sigill.intra.peff.net","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-09T11:07:31Z","receivedAt":"2011-05-09T11:07:31Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Mon, May 9, 2011 at 8:44 PM, Jeff King wrote:\n> On Mon, May 09, 2011 at 06:45:56PM +1000, Jon Seymour wrote:\n>\n>> I am starting to think that deploy-via-zip/tar is unworkable for the\n>> case where the extension wants to supply html, since I think an\n>> attempt has to be made to deploy HTML in the path reported by git\n>> --html-path for reasons of HTML  linkability from extension back to\n>> the pages from git-core.\n>\n> Yeah, I don't see a way around that without post-processing the HTML\n> links at install time (or creating a symlink farm with all of the HTML\n> pages).\n>\n>> So, suppose we call it --preferred-extension-path*, then if the user\n>> (root or otherwise) defines\n>>\n>>     git config core.preferrred-extension-path ${HOME}/.gitplugins\n>>\n>> then they get to choose where the installer next run will install extensions.\n>\n> I thought about suggesting that, but a config option didn't seem a good\n> fit to me. The decision of where to put a package seems more likely to\n> be related to which _package_ it is, than which user you are. So a\n> command-line option would make more sense. And even if you have a config\n> option, you would sitll need a command-line one to override, so it's not\n> like you are reducing the amount of code or complexity.\n>\n> Which again makes it not a git issue at all, but an issue for\n> package-writers who want to provide a script. It's their job to interact\n> with the user and find out where the user wants to put things (i.e.,\n> personal or system directories).\n>\n> I don't really see any need for git's role in this to be more than:\n>\n>  1. Check a set list of directories for extra paths to add to PATH and\n>     MANPATH.\n>\n>  2. Tell the packager's script what that set list is, so they can be\n>     sure to put their files in the right spot.\n>\n\nThe problem with presenting a list of possible directories is that\ngiven a list, the choice is ambiguous. Sure a decision procedure can\nbe arrived at to choose, but it might be hard for the user to predict\nwhat decision the procedure will reach. In that case, the user must be\nprompted for a selection.\n\nIdeally most extension installs would not require any kind of\nconfiguration or decision by the user - simply a statement, I want\nthis installed and I want it to be available immediately.\n\nThe idea, I think, is to make this decision once, not every single\nextension install. Chances are\ngit's default guess will be pretty good (say, /usr/local), but if a\nuser decides that he wants to install\nthis, and all future extensions in ~/.gitplugins, then this can be\nindicated once, with global configuration\nthat overrides the compiled in default.\n\nAgain, part of the idea is to give the extension installer some degree\nof confidence that the selected prefix/bin is, in fact,\nin the path and to give the user an override in case the compiled in\ndefault isn't workable for some reason (for example, due to a\npermissions issue).\n\njon.\n"},{"id":"167487","messageId":"BANLkTimGEU0vFOCEsWaF_T4EOPQwnWip6g@mail.gmail.com","threadId":"27196","inReplyTo":"BANLkTikUjGLBH6_ze7EvRfoKb9h-RREmuA@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-09T11:13:44Z","receivedAt":"2011-05-09T11:13:44Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Mon, May 9, 2011 at 9:07 PM, Jon Seymour wrote:\n> On Mon, May 9, 2011 at 8:44 PM, Jeff King wrote:\n>> On Mon, May 09, 2011 at 06:45:56PM +1000, Jon Seymour wrote:\n>>\n>>> I am starting to think that deploy-via-zip/tar is unworkable for the\n>>> case where the extension wants to supply html, since I think an\n>>> attempt has to be made to deploy HTML in the path reported by git\n>>> --html-path for reasons of HTML  linkability from extension back to\n>>> the pages from git-core.\n>>\n>> Yeah, I don't see a way around that without post-processing the HTML\n>> links at install time (or creating a symlink farm with all of the HTML\n>> pages).\n>>\n>>> So, suppose we call it --preferred-extension-path*, then if the user\n>>> (root or otherwise) defines\n>>>\n>>>     git config core.preferrred-extension-path ${HOME}/.gitplugins\n>>>\n>>> then they get to choose where the installer next run will install extensions.\n>>\n>> I thought about suggesting that, but a config option didn't seem a good\n>> fit to me. The decision of where to put a package seems more likely to\n>> be related to which _package_ it is, than which user you are. So a\n>> command-line option would make more sense. And even if you have a config\n>> option, you would sitll need a command-line one to override, so it's not\n>> like you are reducing the amount of code or complexity.\n>>\n>> Which again makes it not a git issue at all, but an issue for\n>> package-writers who want to provide a script. It's their job to interact\n>> with the user and find out where the user wants to put things (i.e.,\n>> personal or system directories).\n>>\n>> I don't really see any need for git's role in this to be more than:\n>>\n>>  1. Check a set list of directories for extra paths to add to PATH and\n>>     MANPATH.\n>>\n>>  2. Tell the packager's script what that set list is, so they can be\n>>     sure to put their files in the right spot.\n>>\n>\n\nBTW: the reason why I want the git actually installed to provide this\nhint about the best place to install,\nrather than use installation script heuristics is that the locally\ninstalled git + the user supplied configuration\nis in a much better situation to suggest a good choice than an install\nscript that is trying to be platform and distribution agnostic.\n\njon.\n"},{"id":"167488","messageId":"20110509112428.GE9060@sigill.intra.peff.net","threadId":"27196","inReplyTo":"BANLkTikUjGLBH6_ze7EvRfoKb9h-RREmuA@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T11:24:28Z","receivedAt":"2011-05-09T11:24:28Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 09:07:31PM +1000, Jon Seymour wrote:\n\n> > I don't really see any need for git's role in this to be more than:\n> >\n> >  1. Check a set list of directories for extra paths to add to PATH and\n> >     MANPATH.\n> >\n> >  2. Tell the packager's script what that set list is, so they can be\n> >     sure to put their files in the right spot.\n> >\n> \n> The problem with presenting a list of possible directories is that\n> given a list, the choice is ambiguous.\n\nWell, yeah. Though between git and the package script, I think it ends\nup being simplified to the --system-extension-dir thing, because out of\nthe three places I mentioned you might want to install something:\n\n 1. You definitely don't want to install in the distro location. If you\n did, then you would be a distro package, and therefore would not\n have to be asking git where that location is.\n\n 2. You do need to know where the locally-installed system path is, so\n we provide an option to query that.\n\n 3. You don't need to ask git where the per-user path is. It will be at\n some well-known location like $HOME/.gitplugins.\n\nThat being said, I think you are more concerned with not presenting\ntoo many choices to the user. And that still leaves one choice: system\n(2) versus user (3) install.\n\nBut I don't think there's a way around that. You are going to have users\nof both types, and you will want to serve them. You can make a guess\nbased on something like writability of the system directory, I suppose,\nand let them override via the command-line if they want to.\n\nThat strikes me as somewhat flaky and unpredictable, but I am perhaps\nnot a representative sample. I have always thought the Windows \"if you\ninstall as Administrator, it is available to everybody, but otherwise it\nis available only to you\" behavior was confusing, and this seems like\nthe same thing.\n\n> Sure a decision procedure can be arrived at to choose, but it might be\n> hard for the user to predict what decision the procedure will reach.\n> In that case, the user must be prompted for a selection.\n\nI think this is in agreement with what I just wrote above.\n\n> Again, part of the idea is to give the extension installer some degree\n> of confidence that the selected prefix/bin is, in fact, in the path\n> and to give the user an override in case the compiled in default isn't\n> workable for some reason (for example, due to a permissions issue).\n\nSo from this, I gather you would like to see something like:\n\n $ cd git-work && ./install\n fatal: unable to write to /usr/local/share/git: permission denied\n You may install git-work just for the current user with:\n\n ./install --user\n\nI.e., the script has a predictable and sane behavior, but you guide the\nuser through overriding it if need be. That doesn't seem unreasonable to\nme.\n\nAnyway, with respect to \"core.preferredPluginPath\", if you do want to go\nin that direction, I don't think any extra git support is needed. You\ncan already just do \"git config --path core.preferredPluginPath\" to get\nthe value (with tilde-expansion, even).\n\n-Peff\n"},{"id":"167489","messageId":"BANLkTikQQNoYf=vZwMwAXPu0-S_2s9Y79w@mail.gmail.com","threadId":"27196","inReplyTo":"20110509112428.GE9060@sigill.intra.peff.net","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-09T11:28:26Z","receivedAt":"2011-05-09T11:28:26Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Mon, May 9, 2011 at 9:24 PM, Jeff King wrote:\n> On Mon, May 09, 2011 at 09:07:31PM +1000, Jon Seymour wrote:\n>\n>> > I don't really see any need for git's role in this to be more than:\n>> >\n>> >  1. Check a set list of directories for extra paths to add to PATH and\n>> >     MANPATH.\n>> >\n>> >  2. Tell the packager's script what that set list is, so they can be\n>> >     sure to put their files in the right spot.\n>> >\n>>\n>> The problem with presenting a list of possible directories is that\n>> given a list, the choice is ambiguous.\n>\n> Well, yeah. Though between git and the package script, I think it ends\n> up being simplified to the --system-extension-dir thing, because out of\n> the three places I mentioned you might want to install something:\n>\n>  1. You definitely don't want to install in the distro location. If you\n>     did, then you would be a distro package, and therefore would not\n>     have to be asking git where that location is.\n>\n>  2. You do need to know where the locally-installed system path is, so\n>     we provide an option to query that.\n>\n>  3. You don't need to ask git where the per-user path is. It will be at\n>     some well-known location like $HOME/.gitplugins.\n>\n> That being said, I think you are more concerned with not presenting\n> too many choices to the user. And that still leaves one choice: system\n> (2) versus user (3) install.\n>\n> But I don't think there's a way around that. You are going to have users\n> of both types, and you will want to serve them. You can make a guess\n> based on something like writability of the system directory, I suppose,\n> and let them override via the command-line if they want to.\n>\n> That strikes me as somewhat flaky and unpredictable, but I am perhaps\n> not a representative sample. I have always thought the Windows \"if you\n> install as Administrator, it is available to everybody, but otherwise it\n> is available only to you\" behavior was confusing, and this seems like\n> the same thing.\n>\n>> Sure a decision procedure can be arrived at to choose, but it might be\n>> hard for the user to predict what decision the procedure will reach.\n>> In that case, the user must be prompted for a selection.\n>\n> I think this is in agreement with what I just wrote above.\n>\n>> Again, part of the idea is to give the extension installer some degree\n>> of confidence that the selected prefix/bin is, in fact, in the path\n>> and to give the user an override in case the compiled in default isn't\n>> workable for some reason (for example, due to a permissions issue).\n>\n> So from this, I gather you would like to see something like:\n>\n>  $ cd git-work && ./install\n>  fatal: unable to write to /usr/local/share/git: permission denied\n>  You may install git-work just for the current user with:\n>\n>    ./install --user\n>\n> I.e., the script has a predictable and sane behavior, but you guide the\n> user through overriding it if need be. That doesn't seem unreasonable to\n> me.\n>\n> Anyway, with respect to \"core.preferredPluginPath\", if you do want to go\n> in that direction, I don't think any extra git support is needed. You\n> can already just do \"git config --path core.preferredPluginPath\" to get\n> the value (with tilde-expansion, even).\n>\n> -Peff\n>\n\nI still think it would be useful for the git wrapper to add\ncore.preferredPluginPrefix/bin to\nthe PATH, so that there is no requirement for the user to do this\nseparately via mechanisms\nthat will differ according to platform, shell etc.\n\njon.\n"},{"id":"167491","messageId":"20110509122137.GA10095@sigill.intra.peff.net","threadId":"27196","inReplyTo":"BANLkTikQQNoYf=vZwMwAXPu0-S_2s9Y79w@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2011-05-09T12:21:37Z","receivedAt":"2011-05-09T12:21:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, May 09, 2011 at 09:28:26PM +1000, Jon Seymour wrote:\n\n> > Anyway, with respect to \"core.preferredPluginPath\", if you do want to go\n> > in that direction, I don't think any extra git support is needed. You\n> > can already just do \"git config --path core.preferredPluginPath\" to get\n> > the value (with tilde-expansion, even).\n> \n> I still think it would be useful for the git wrapper to add\n> core.preferredPluginPrefix/bin to the PATH, so that there is no\n> requirement for the user to do this separately via mechanisms that\n> will differ according to platform, shell etc.\n\nAh, yeah, that probably does make sense.\n\nMy original conception was that it would be more like\n\"preferredExtensionType\" and would be either \"user\" or \"system\", from\nwhich the installer would select either \"$HOME/.gitplugins\" or \"git\n--system-extension-dir\" respectively. And I was still thinking in those\nterms, even though the example you showed was obviously an arbitrary\npath.\n\nIf you want to go the arbitrary path route, then yeah, it would need to\nbe added to git's expansion list.\n\nThere is one drawback with that, though. Consider something like this:\n\n $ git config core.preferredPluginPrefix /opt/git-plugins\n $ cd git-foo && ./install\n [installs in /opt/git-plugins/git-foo]\n $ git foo ;# works fine\n\n [time passes; now you decide you want to install new plugins in your\n home directory]\n $ git config core.preferredPluginPrefix $HOME/.gitplugins\n $ cd git-bar && ./install\n [installs in $HOME/.gitplugins]\n $ git bar ;# works fine\n $ git foo ;# now broken!\n\nSo there is some value to separating the concept of \"these are the paths\ngit looks in\" and \"this is the path we install into\" and enforcing that\nthe latter points to one of the former.\n\n-Peff\n"},{"id":"167546","messageId":"BANLkTikbtGyP5esExySif074OpEoDMdhfg@mail.gmail.com","threadId":"27196","inReplyTo":"20110509122137.GA10095@sigill.intra.peff.net","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Jon Seymour","fromEmail":"jon.seymour@gmail.com","sentAt":"2011-05-09T22:50:10Z","receivedAt":"2011-05-09T22:50:10Z","isPatch":false,"sender":{"key":"jon.seymour@gmail.com","avatar":"https://avatars.githubusercontent.com/u/207131?v=4"},"body":"On Mon, May 9, 2011 at 10:21 PM, Jeff King wrote:\n> On Mon, May 09, 2011 at 09:28:26PM +1000, Jon Seymour wrote:\n>\n>> > Anyway, with respect to \"core.preferredPluginPath\", if you do want to go\n>> > in that direction, I don't think any extra git support is needed. You\n>> > can already just do \"git config --path core.preferredPluginPath\" to get\n>> > the value (with tilde-expansion, even).\n>>\n>> I still think it would be useful for the git wrapper to add\n>> core.preferredPluginPrefix/bin to the PATH, so that there is no\n>> requirement for the user to do this separately via mechanisms that\n>> will differ according to platform, shell etc.\n>\n> Ah, yeah, that probably does make sense.\n>\n> My original conception was that it would be more like\n> \"preferredExtensionType\" and would be either \"user\" or \"system\", from\n> which the installer would select either \"$HOME/.gitplugins\" or \"git\n> --system-extension-dir\" respectively. And I was still thinking in those\n> terms, even though the example you showed was obviously an arbitrary\n> path.\n>\n> If you want to go the arbitrary path route, then yeah, it would need to\n> be added to git's expansion list.\n>\n> There is one drawback with that, though. Consider something like this:\n>\n>  $ git config core.preferredPluginPrefix /opt/git-plugins\n>  $ cd git-foo && ./install\n>  [installs in /opt/git-plugins/git-foo]\n>  $ git foo ;# works fine\n>\n>  [time passes; now you decide you want to install new plugins in your\n>   home directory]\n>  $ git config core.preferredPluginPrefix $HOME/.gitplugins\n>  $ cd git-bar && ./install\n>  [installs in $HOME/.gitplugins]\n>  $ git bar ;# works fine\n>  $ git foo ;# now broken!\n>\n> So there is some value to separating the concept of \"these are the paths\n> git looks in\" and \"this is the path we install into\" and enforcing that\n> the latter points to one of the former.\n\nFair point. I'll ponder this some more.\n\nThanks,\n\njon.\n"},{"id":"171907","messageId":"20110513193233.GC24644@nibiru.local","threadId":"27196","inReplyTo":"BANLkTim=ARYu=E-Lgu8dA+FpVQUY+q-yeA@mail.gmail.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"Enrico Weigelt","fromEmail":"weigelt@metux.de","sentAt":"2011-05-13T19:32:34Z","receivedAt":"2011-05-13T19:32:34Z","isPatch":false,"sender":{"key":"weigelt@metux.de","avatar":null},"body":"* Jon Seymour wrote:\n\n> No. As I explained in the posts\n> that you chose not to read, such concerns would be dealt with by real\n> package managers.\n\nOkay, you're essentially aliasing git-pm to the distro's existing\npackage manager. In the end, these git extensions still have to\nbe packaged for your actual distro. So why not just using the\ndistro's package manager directly ?\n\n\ncu\n-- \n----------------------------------------------------------------------\n Enrico Weigelt, metux IT service -- http://www.metux.de/\n\n phone: +49 36207 519931 email: weigelt@metux.de\n mobile: +49 151 27565287 icq: 210169427 skype: nekrad666\n----------------------------------------------------------------------\n Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme\n----------------------------------------------------------------------\n"},{"id":"167840","messageId":"20110514125133.GA765@gmail.com","threadId":"27196","inReplyTo":"buozkmw5w3j.fsf@dhlpc061.dev.necel.com","subject":"Re: RFC: a plugin architecture for git extensions?","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2011-05-14T12:51:36Z","receivedAt":"2011-05-14T12:51:36Z","isPatch":false,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Mon, May 09, 2011 at 01:36:16PM +0900, Miles Bader wrote:\n> Junio C Hamano writes:\n> > Do you or do you not run \"apt-get install git-superadd\"?\n> >\n> > One possible answer may be to run \"apt-get install git-superadd\", and then\n> > the users who want \"git add\" to behave in a new way to opt-in to use the\n> > \"plug-in\". I think that is what Jon is getting at.\n> \n> If aliases could override built-in command names, it'd be easy enough\n> (\"alias add=superadd\") ... [with some feature to allow suppressing the\n> alias to prevent recursion, e.g. an environment variable or something.]\n\nI always thought this restriction was a good thing.\n\nThe usability argument usually goes that it's generally\nbad for \"git frotz\" somewhere to behave different from\n\"git frotz\" somewhere else.\n\nKeeping this \"limitation\" is good for the sake of consistency.\n\nThis topic is orthogonal to the plugin rfc, though.\n-- \n\t\t\t\t\tDavid\n"}]}