Heya, On Mon, Nov 30, 2009 at 09:49, Junio C Hamano <gitster@xxxxxxxxx> wrote: > Sorry, I don't understand that. With that reasoning, isn't having a > single git package, be it python or not, even easier? Why would anybody > want a separate egg that includes everything that _happen_ to be written > in Python in the first place? It doesn't make sense at all from packaging > point of view to me. Because that's the recommended way to create a python package, create a new directory, put the files in it, and distribute it. > A separate egg per remote-helper that you can pick and choose which ones > to install and which ones to leave out would make perfect sense, exactly > the same way that distros already split git into "git-core", "git-svn", > etc., though. Your "git-hg" may consist of a single egg and perhaps some > other supporting code, and people who want to convert away from legacy Hg > repository may want to install it, but it is entirely up to them if they > also want to install "git-cvs" that is implemented as a remote-helper that > happens to be written in Python, no? Yes, fair enough, but we don't do that for any other files in git.git. The packagers do so, sure, but a different concern. The reason we want to distribute the git_remote_helpers package is so that git-remote-hg.py, which lives in git.git/ and is installed as git-remote-hg can say "from git_remote_helpers.hg import export". The only reason this is needed in the first place is because we can't just add the python files to libgit.a or embed it in git-remote-hg statically, python does not support that. That is the only reason we need to distribute the package, which is why we need a separate directory. That is, if I've understood Johan's reasoning and intention correctly. -- Cheers, Sverre Rabbelier -- 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