From mboxrd@z Thu Jan 1 00:00:00 1970 From: Jon Seymour Subject: Re: RFC: a plugin architecture for git extensions? Date: Thu, 28 Apr 2011 10:50:47 +1000 Message-ID: References: <4DB80747.8080401@op5.se> <4DB82D90.6060200@op5.se> <7vbozr8uo8.fsf@alter.siamese.dyndns.org> <7vpqo77dlr.fsf@alter.siamese.dyndns.org> <1303930175.25134.38.camel@drew-northup.unet.maine.edu> <20110427194233.GA16717@gnu.kitenet.net> <7vwrif5q93.fsf@alter.siamese.dyndns.org> <20110427220748.GA19578@elie> <7vsjt35l84.fsf@alter.siamese.dyndns.org> <20110427234224.GA26854@elie> <7viptz5j82.fsf@alter.siamese.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: QUOTED-PRINTABLE Cc: Jonathan Nieder , Joey Hess , Git Mailing List To: Junio C Hamano X-From: git-owner@vger.kernel.org Thu Apr 28 02:50:57 2011 Return-path: Envelope-to: gcvg-git-2@lo.gmane.org Received: from vger.kernel.org ([209.132.180.67]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1QFFRX-0002nj-Ny for gcvg-git-2@lo.gmane.org; Thu, 28 Apr 2011 02:50:56 +0200 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752421Ab1D1Auu convert rfc822-to-quoted-printable (ORCPT ); Wed, 27 Apr 2011 20:50:50 -0400 Received: from mail-ew0-f46.google.com ([209.85.215.46]:47497 "EHLO mail-ew0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752249Ab1D1Aut convert rfc822-to-8bit (ORCPT ); Wed, 27 Apr 2011 20:50:49 -0400 Received: by ewy4 with SMTP id 4so677703ewy.19 for ; Wed, 27 Apr 2011 17:50:48 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type :content-transfer-encoding; bh=XGtjkOa9syvyUAhiGji5u5eVtb73jM3PWzmtLa+ZNCE=; b=AIP4wJyuazus1vKDogGvVN1va3vh4vBe213iJ8vpv+7YtFBZvYfL38T08sQNHyIQdU siL/0FGgRNZdu/sTv7Epl9HSj3vKMc/55Rz5fV/pK7woKqYMH9KdKqmfxdGDmefOci4g 6miJ87b4XnZCT+QkXWyitXa6OBuWHxD4/IQ/w= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:content-transfer-encoding; b=QfvDcJs7yvinc1ShuhcxHT4QmwDDiqXmDs0oMLH39zoFsQXn9kqQJ2QjNwFYYP8NJ4 B9qYj0YSMGqTj/0NBGgGVgo6ObAuZS3GYIJBn/1KpOtpt6Rj0lO/69q6VYEOiW6uD/m9 v8txiLopT3LF8AZhbtSzQjuJHfxQXf3238cdc= Received: by 10.14.6.10 with SMTP id 10mr1209361eem.117.1303951848045; Wed, 27 Apr 2011 17:50:48 -0700 (PDT) Received: by 10.14.22.68 with HTTP; Wed, 27 Apr 2011 17:50:47 -0700 (PDT) In-Reply-To: <7viptz5j82.fsf@alter.siamese.dyndns.org> Sender: git-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: git@vger.kernel.org Archived-At: On Thu, Apr 28, 2011 at 10:10 AM, Junio C Hamano wr= ote: > Jonathan Nieder writes: > >> Right, my worry was based on the usual way programs find their way >> onto my $PATH. =C2=A0That is: >> >> =C2=A0- if they are installed via a package from the distro, they ar= e in >> =C2=A0 =C2=A0/usr/bin. >> >> =C2=A0- if they are installed with "make install" by the local sysad= min for >> =C2=A0 =C2=A0all users, they are in /usr/local/bin. >> >> =C2=A0- if I am trying them out for myself, they are in $HOME/opt/fo= o/bin >> =C2=A0 =C2=A0and when it is time to remove it, "rm -fr $HOME/opt/foo= ". >> >> =C2=A0- if I have adopted them, symlinks go in $HOME/bin. >> >> With a local gcc-4.6 in $HOME/bin, if the sysadmin upgrades gcc so >> gcc-4.6 is to appear in /usr/bin or /usr/local/bin, my setup still >> works without trouble. =C2=A0So, barring bugs, each installation met= hod >> does not interfere with the other ones. >> >> Call it overengineering, but I would want a way for installing new g= it >> commands to have the same attributes (installable by normal users in >> multiuser systems and name conflicts not being a terrible >> administrative burden). > > Ok, I wasn't thinking about folks who use repackaged /usr/bin/git tog= ether > with their own choice of third-party enhancements. > > Probably we would be better off if we define a new set of paths that = is > independent from GIT_EXEC_PATH and friends. =C2=A0The installed git a= nd nothing > else will occupy GIT_EXEC_PATH etc., but at the runtime, git would lo= ok at > a user-writable location GIT_PLUGIN_PATH/{bin,man,...} to see if the = user > has her own customization, and add them to its vocabulary. > > Or something like that. =C2=A0I am not all that interested, but it fe= els like a > good direction. > I agree. Apologies for confusing things by talking too much about a git pm install command. I think there are 3 levels of functionality. FWIW, I am suggesting git-core stops at #2. 0. unmanaged plugins git doesn't provide any explicit management of plugins, but will use them if finds them. Without some kind of management, however, you will be forced to dump the man pages and scripts for the plugins in one place. This would be very distribution manager unfriendly since there could be conflicts galore. I guess an unmanaged solution could use separate directories for each plugin, but this would imply scanning all these paths each time you invoke git. In my view, symbolic links from a dir already GIT_EXEC_PATH to plugin directories would be a more efficient way to do this. 1. managed plugins git provides minimal plugin management functionality. Each plugin has its own directory, but an activate step is required to make the plugin available to the GIT_EXEC_PATH and GIT_MAN_PATH. This has the advantage that conflicts between plugins would be more readily avoided and is potentially more performant. As Pau suggests, this option is much more package manager friendly It probably does require a git plugin command of some kind, however, in order to perform the activation step. 2. managed packages A meta-package manager for plugins, that delegates plugin installation concerns to a platform package manager. The thing is, you may absolutely hate #2, but if approach #1 is adopted by git-core, someone can at least attempt this by, well, writing a plugin for it. jon.