On Thu, Apr 28, 2011 at 12:52 AM, Andreas Ericsson <ae@xxxxxx> wrote: > 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. >> 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. > 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 > > 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. > > So the complete description would be > > Âgit clone git://somerepo/gitworks > Âcd gitworks > Âmake install Still more than 4 words. 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