Re: RFC: a plugin architecture for git extensions?

From: Jon Seymour <jon.seymour@gmail.com>
Date: Apr 27, 2011, 15:36 UTC
Message-ID: <BANLkTi=XcR9FTPC8oe100fMneNf1nca4_Q@mail.gmail.com>
In-Reply-To: <4DB82D90.6060200@op5.se>

On Thu, Apr 28, 2011 at 12:52 AM, Andreas Ericsson <ae@op5.se> wrote:

Show 38 quoted lines

> On 04/27/2011 02:50 PM, Jon Seymour wrote:
>> On Wednesday, April 27, 2011, Andreas Ericsson  wrote:
>>> On 04/27/2011 05:36 AM, Jon Seymour wrote:
>>>> Has anyone ever given consideration to git supporting a plugin
>>>> architecture for git extensions?
>>>>
>>>> The idea would be to provide a consistent way to install, and address
>>>> extensions to the core git functionality in a manner that does not
>>>> require the extension to actually be integrated into the git core.
>>>>
>>>
>>
>>> Horrible idea. There are already as many package managers as there
>>> are packages without us throwing another one into the mix.
>>>
>>
>> I agree that there are too many package managers. But do you know
>> what? There isn't a single package manager that reliably works across
>> platform. apt-get? great. Except you need something else for Mac,
>> cywgin, or, um Fedora. Brew? Fine then you only need to worry about
>> Linux and cygwin. Cygwin? ...
>>
>> The platform for my extension is git. Not Mac. Not Debian. Not Fedora.
>> Not cygwin. git.
>>
>> The lowest common denominator across these environments is, um, git.
>>
>
> You're utterly horribly wrong. It'll work well enough for scripted
> languages but when you start mixing in compiler requirements and
> whatnot the scheme falls apart. Quickly. Binary packages are popular
> for (very good) reasons: They are simple, fast and there's a
> reasonable chance they've been tested fairly well with the rest of
> the system so nothing breaks horribly once you install it.
> Perl, Ruby, Python and PHP all have their own extension installers.
> That makes perfect sense since the same code runs unchanged on all
> platforms (with some few exceptions).
>

Yeah, but that's when you delegate to a OS-specific package manager.

Concens. Separated. Good principle, that.

Show 21 quoted lines

>> I challenge the sceptIcs to specify a one line command script that
>> works across all possible environment that is more succinct than:
>>
>>     git pm install gitwork
>>
>
> That's not the point. Mac users supposedly already know about brew.
> Fedora users already know about yum. Cygwin users... well, I have
> no idea what they know about, but whatever it is, it's fairly safe
> to assume they already know about it. That means they'll turn to
> that familiar tool for managing packages when they want to install
> something new. What you're proposing would force users on *all*
> systems to have to learn a new one.
>
>> It shouldn't be too hard. A tar command here, an enviroment  variable
>> edit there. Perhaps a curl command or a browser download.
>>
>
> And what you get in the end is a f*cking mess of spaghetti shell
> code that works worse than the existing package managers.
>

I guess that really depends on who you ask to write the shell script.

Most package managers have fairly straight forward interfaces.

   brew install blah
   apt-get install blah
   git clone git://github.com/blah/blah

There is no reason why some with a modicum of shell scripting nous could not whip together a simple meta interface for platform-specific package managers that knows how to:

* read a specification from a git config file
* apply that specification to the task of invoking a platform specific
package manager.

Some one really smart could probably do it in an extensible way that coped with the concept that different OS-platforms have different package managers.

Most of this pasta can be cooked once, by the person who writes gpm/git-pm. Sauce would be extra, of course.

Show 10 quoted lines

> And you're right. It's not too hard, so long as every extension
> manager maintains some short list of requirements in the proper
> format, which current package maintainers will have to learn if
> they want some modules to be part of the "default" system install,
> the way a whole bunch of Perl modules are.
>
>> You have 4 words. Knock yourself out.
>>
>
> make install

Show 7 quoted lines

>
> Made it in 2. What you described is what the user does to get
> new extensions. What I described below is what developers have
> to do to make their extensions easy to install *without* a
> package manager even if the distro the user is on doesn't ship
> that particular extension.
>

Again, there is a package called gitwork, available. It is available as a tarball. Somewhere. Install it.

* look up the url (google, might help)
* dowload it with your favourite download tool (browser, curl)
* unpack it
* install its dependencies, if required
* configure it
* buiild it

Your two words only specified the very last step. I needed 6 bullet points merely to explain the details you omitted.

Show 6 quoted lines

>
> So the complete description would be
>
>  git clone git://somerepo/gitworks
>  cd gitworks
>  make install

Still more than 4 words.

jon.