On Sat, May 7, 2011 at 12:50 AM, Jonathan Nieder <jrnieder@xxxxxxxxx> wrote: > Jon Seymour wrote: > >> Partly because that is second guessing &/or reverse engineering the >> distribution's decisions and > > Well, no --- that's what /usr/local is _for_: > http://www.pathname.com/fhs/pub/fhs-2.3.html#USRLOCALLOCALHIERARCHY > Sorry, what I really meant to say is that /usr/local/bin is not always in a user's path *** . Whether it is or not depends in part on which distribution manager you use on MAC OSX [ brew does user /usr/local, but MAC Ports uses /opt/local ]. *** I may be wrong about this - /usr/local/bin is actually in my MAC's path, but I think I had to edit /etc/profile to get it there. That said, once git is installed, there is usually a directory like /usr/local or /opt/local that could be used as the default prefix to target the installation of a plugin. Perhaps there is a case for a git --prefix to provide that hint? >> it won't work for a Windows install where there is no /usr/local > > That's true. ÂI believe command-line users on Windows who install by > unzipping to a directory are used to having to set a PATH for > themselves. ÂPerhaps it would be convenient for git to learn to add a > specific standard directory to its private PATH as a Windows-specific > extension, though. > > If your goal is to make installing new commands for git easier than > installing native apps --- why? ÂIt seems backwards. ÂConsider that > the end result ought to be easy not only for the app developer but for > the end user, and if every program with the ability to call other > programs sets up its own better replacement for standard operating > system facilities, that will make for a complicated system to > administer indeed. ÂSo with that in mind, it might be simpler to take > advantage of existing project that simplifies installation of native > apps, like <http://zero-install.sourceforge.net/>. > I will have a look at zero-install, though quick inspection seems to indicate that it is best for running standalone apps and not necessarily great for the task at hand here. The idea isn't to replace standard operating system facilities for application installation. The idea is to provide a uniform interface for accomplishing the rather limited task of extending git that can work the same way, irrespective of platform, irrespective of file system layouts, irrespective of assumptions about which directories are already in the user's paths. One answer is for each extension author to invent their own way to produce packages that can be installed in a cross-platform way across multiple platforms but this seems like an unnecessary duplication of effort compared to a possible alternative. If at the end of the day, we say make and install are the way to do it, then fine. However, this makes the dependencies for a successful install strictly greater than the existence of git and a POSIX shell which we can assume if git is already installed. 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