On Wed, Apr 27, 2011 at 07:59:33PM +1000, Jon Seymour wrote: > 2011/4/27 Motiejus JakÅtys <desired.mta@xxxxxxxxx>: > > On Wed, Apr 27, 2011 at 06:40:07PM +1000, Jon Seymour wrote: > > Although this looks very nice from user point of view, it would be a > > pain for the extension maintainer... Though it's only one C file. > > > > I don't see why. You wouldn't be forced to maintain one of those > packages, anymore than you are now. If you can, you just publish a git > url, and your job is done. If your tool requires compilation, you > have already solved the distribution problem for the package managers > you choose to support. > > All I am suggesting you do is that you list pointers to these > packages, which gpm could then use to actually do the installation for > you. > > The thing I really care about is: once the package has been installed > locally, how do I activate it and makes its features available to the > git runtime, without having to futz around with my PATH, MANPATH etc? > > Yes, this is user focused. I want users of my tool to be able to > something like: > > git pm install gitwork > > or perhaps: > > git pm install git://github.com/jonseymour/gitwork > > And then start using it. I want the git completions to be there, I > want the man pages to be there. I want the scripts to be there. In my > case, there I really shouldn't have to do anything other than point at > a git url, get the package transported to a local directory and > activate it. > > I want to tell my users what they need to do to install my extension > without having to have variants of the instructions for zip/tar > people, apt-get people, brew people, MAC ports people, yum people etc. > Yes, for compiled stuff, someone has to prepare the packages. But once > they are prepared, use whatever package manager the user uses to > install it and expose the gpm config required to activate it. python virtualenv has very similar goals and does the same thing, the only difference is you have to "source env/bin/activate" before using your local modules (or run env/bin/python). I can clarify what features from it could be used for git, if you like. > > I think shipping it in contrib/ and having extension system is a better > > option. Though it leaves a hole for dependencies -- if my logx depends > > on boost or imagemagick, we don't want make git depend on it... > > > > Unless I am misunderstanding something about how contrib/ is managed > that still requires Junio to be in the loop, which defeats one of my > objectives here - which is to allow anyone to contribute and share > their own extensions without being bottlenecked by someone else's > release cycle. Yes, you are right. It shouldn't. Like in python. Motiejus -- 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