On Thu, Apr 28, 2011 at 7:25 PM, Andreas Ericsson <ae@xxxxxx> wrote: > On 04/28/2011 04:49 AM, Jon Seymour wrote: >> On Thu, Apr 28, 2011 at 12:15 PM, Jon Seymour<jon.seymour@xxxxxxxxx> wrote: >>> Then a command like: >>> >>> git install gitwork >>> >>> would trivially work across all distributions precisely because the >>> distribution has provided the implementation of the git install >>> interface contract that git-core has helpfully mandated. >>> >> >> Or better yet, git-core could provide a trivial git install >> implementation that selects between different distribution manager >> supplied plugins selected according to some heuristic, allowing >> several distribution managers to happily manage plugins in the same >> git instance. >> >> I have to ask. >> >> Is such an architecture really "absolutely horrid"? Is it "crap"? Really? >> > > Yes, because it forces all distributions to name their extensions > the same and it forces all distributions to carry the same extensions. False. Distributions maintain a N:1 registry of git plugin names to distribution specific package names. This registry would most naturally be maintained by the author who maintains the git package, but of course, such responsibilities could be delegated to others if required. During installation, the package manage aware "install" plugin consults such a registry to determine which packages need to be installed in order to obtain the requested plugin. It then asks the package manager to install said packages. > It also makes it impossible to support 3rd party extensions that core > git doesn't know about and that aren't already packaged, unless you > want the "git install" command to have knowledge about all package > management systems and *very, very good* heuristics when guessing what > a particular extension is called on that system. > Again false. That is the role of the registry that is maintained by some package author. > What will happen though is that the distributions will happily ignore > that and the "git install" command will fail for some extensions on > some distributions. Yes, but it can fail in a extremely precise way. In those cases, it could fall back another package manager such as one that is capable of checking out a git repo and running make install. I realise that most people could not accomplish such a task without writing vast amounts of spaghetti code, but there you go. > > Besides that, it forces users to install git from their distribution > packages so we're hard-shafting the git developers who usually have > at least some installations done from source. > No it doesn't. My suggestion allows deploy by drop-in configuration to a subdirectory of plugins/ followed by the invocation of a command such as. git plugin activate foobar I realise this may "hard-shaft" the git developers who are unable to invoke a git command, but I guess they could also put such a command in their make install scripts. Now there's an idea. > We just went far beyond "absolutely horrid" and into the realms of > "steaming pile of abominably manure-like ideas whose inventor should > be slapped silly for their own good". > Thanks, I'll add that to my vocabulary of terms that git developers use when they let fly to their emotions for completely unaccountable reasons. I'd suggest,. perhaps "grow up", but that would strike some as rude. So, I won't. > So let's get back to the basic wish you have here. You want people > to be able to easily find, download and install "git work" so that it > works nicely with man-pages and all. > What is so hard about: app install plugin. Forget git. Forget git work. What is so hard about the concept of an application providing a facility that allows it to request, merely request, the installation of a plugin for itself by what ever happens to be the users choice of package manager or distribution. Is such a concept really, fundamentally flawed? if so, replace "git" with "linux", "app" with "apt-get", "plugin" with "git-core" and explain to me why apt-get install git-core is such a bad idea. Yes, different levels of abstraction, but the principles are the same. Like it or not, git is a platform, there is absolutely no reason why it can't have sane plugin manager, other than complete lack of imagination. > The wiki-page with known extensions and the patch to core git so that > "make install" can put man-pages in the right directory are the first, > simplest and smallest steps that takes us the farthest towards that > wish without burdening people you have no control over with more labor. > In short; It's both good engineering and polite to implement that and > then consider what new possibilities open up and see what people do > with those possibilities. You might be surprised. Yep, that's what unix package management was like before people invented the idea of package managers. How quaint. jon. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html