{"thread":{"id":"21793","subject":"[PATCH] tests: handle NO_PYTHON setting","startedAt":"2009-11-30T07:52:21Z","lastAt":"2009-11-30T22:31:41Z","messageCount":16,"participants":["Jeff King","Sverre Rabbelier","Junio C Hamano","Johan Herland","Brandon Casey"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"128740","messageId":"20091130075221.GA5421@coredump.intra.peff.net","threadId":"21793","inReplyTo":null,"subject":"[PATCH] tests: handle NO_PYTHON setting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-30T07:52:21Z","receivedAt":"2009-11-30T07:52:21Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"Without this, test-lib checks that the git_remote_helpers\ndirectory has been built. However, if we are building\nwithout python, we will not have done anything at all in\nthat directory, and test-lib's sanity check will fail.\n\nSigned-off-by: Jeff King \n---\nOn top of sr/vcs-helper.\n\nThis feels a little funny for NO_PYTHON to mean \"no remote helpers at\nall\". But that is the way the Makefile is set up, since we seem to have\nonly python helpers.\n\n Makefile | 1 +\n t/test-lib.sh | 2 +-\n 2 files changed, 2 insertions(+), 1 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 42744a4..443565e 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1743,6 +1743,7 @@ GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS\n \t@echo TAR=\\''$(subst ','\\'',$(subst ','\\'',$(TAR)))'\\' >>$@\n \t@echo NO_CURL=\\''$(subst ','\\'',$(subst ','\\'',$(NO_CURL)))'\\' >>$@\n \t@echo NO_PERL=\\''$(subst ','\\'',$(subst ','\\'',$(NO_PERL)))'\\' >>$@\n+\t@echo NO_PYTHON=\\''$(subst ','\\'',$(subst ','\\'',$(NO_PYTHON)))'\\' >>$@\n \n ### Detect Tck/Tk interpreter path changes\n ifndef NO_TCLTK\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 4a40520..ca0839c 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -638,7 +638,7 @@ test -d ../templates/blt || {\n \terror \"You haven't built things yet, have you?\"\n }\n \n-if test -z \"$GIT_TEST_INSTALLED\"\n+if test -z \"$GIT_TEST_INSTALLED\" && test -z \"$NO_PYTHON\"\n then\n \tGITPYTHONLIB=\"$(pwd)/../git_remote_helpers/build/lib\"\n \texport GITPYTHONLIB\n-- \n1.6.6.rc0.327.gd49b\n"},{"id":"128742","messageId":"fabb9a1e0911292355v260b9f0ck79d993e25f0c5c61@mail.gmail.com","threadId":"21793","inReplyTo":"20091130075221.GA5421@coredump.intra.peff.net","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-30T07:55:51Z","receivedAt":"2009-11-30T07:55:51Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Nov 30, 2009 at 08:52, Jeff King wrote:\n> This feels a little funny for NO_PYTHON to mean \"no remote helpers at\n> all\". But that is the way the Makefile is set up, since we seem to have\n> only python helpers.\n\nI don't understand what you mean? Do you mean NO_PYTHON implies \"no\nremote helpers at all\", or \"not having any remote helpers\" implies\nNO_PYTHON? Either way, I'm not sure how to set it up differently, not\nhaving that much Makefile foo myself, so maybe Johan and Daniel could\ncomment?\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"128743","messageId":"20091130075927.GA5767@coredump.intra.peff.net","threadId":"21793","inReplyTo":"fabb9a1e0911292355v260b9f0ck79d993e25f0c5c61@mail.gmail.com","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-30T07:59:27Z","receivedAt":"2009-11-30T07:59:27Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 30, 2009 at 08:55:51AM +0100, Sverre Rabbelier wrote:\n\n> > This feels a little funny for NO_PYTHON to mean \"no remote helpers at\n> > all\". But that is the way the Makefile is set up, since we seem to have\n> > only python helpers.\n> \n> I don't understand what you mean? Do you mean NO_PYTHON implies \"no\n> remote helpers at all\", or \"not having any remote helpers\" implies\n> NO_PYTHON? Either way, I'm not sure how to set it up differently, not\n> having that much Makefile foo myself, so maybe Johan and Daniel could\n> comment?\n\nI mean, I would think that the \"git_remote_helpers\" directory contained\nremote helpers of all sorts, not just the python ones. Right now we\n_only_ have python ones. So checking for NO_PYTHON in test-lib.sh before\nlooking at git_remote_helpers makes sense. But I am concerned that\nassumption will be broken silently in the future if non-python helpers\nare added to git_remote_helpers.\n\nIt is probably not worth caring about too much, though.\n\n-Peff\n"},{"id":"128744","messageId":"fabb9a1e0911300004w36c5da45q354aa4ff3153b6f4@mail.gmail.com","threadId":"21793","inReplyTo":"20091130075927.GA5767@coredump.intra.peff.net","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-30T08:04:25Z","receivedAt":"2009-11-30T08:04:25Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Nov 30, 2009 at 08:59, Jeff King wrote:\n> I mean, I would think that the \"git_remote_helpers\" directory contained\n> remote helpers of all sorts, not just the python ones.\n\nI don't think that's true, git.git currently does not have such a\nstructure (everything is just dumped in the root directory). The only\nreason git_remote_helpers exists is to make it easier to create a\npython egg out of it and install that. At least, that's what I think\nis going on, Johan and Daniel might have comments to the contrary.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"128745","messageId":"20091130080553.GA8155@coredump.intra.peff.net","threadId":"21793","inReplyTo":"fabb9a1e0911300004w36c5da45q354aa4ff3153b6f4@mail.gmail.com","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-30T08:05:53Z","receivedAt":"2009-11-30T08:05:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 30, 2009 at 09:04:25AM +0100, Sverre Rabbelier wrote:\n\n> On Mon, Nov 30, 2009 at 08:59, Jeff King wrote:\n> > I mean, I would think that the \"git_remote_helpers\" directory contained\n> > remote helpers of all sorts, not just the python ones.\n> \n> I don't think that's true, git.git currently does not have such a\n> structure (everything is just dumped in the root directory). The only\n> reason git_remote_helpers exists is to make it easier to create a\n> python egg out of it and install that. At least, that's what I think\n> is going on, Johan and Daniel might have comments to the contrary.\n\nOK. It is just my confusion, then. Don't worry about it.\n\n-Peff\n"},{"id":"128749","messageId":"7v4oocwh5o.fsf@alter.siamese.dyndns.org","threadId":"21793","inReplyTo":"fabb9a1e0911300004w36c5da45q354aa4ff3153b6f4@mail.gmail.com","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-30T08:28:19Z","receivedAt":"2009-11-30T08:28:19Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> On Mon, Nov 30, 2009 at 08:59, Jeff King wrote:\n>> I mean, I would think that the \"git_remote_helpers\" directory contained\n>> remote helpers of all sorts, not just the python ones.\n>\n> I don't think that's true, git.git currently does not have such a\n> structure (everything is just dumped in the root directory). The only\n> reason git_remote_helpers exists is to make it easier to create a\n> python egg out of it and install that.\n\nIf that is the case, shouldn't each of the helper written in Python need\nto have a separate directory, not just a single git_remote_helpers\ndirectory shared among them?\n"},{"id":"128751","messageId":"fabb9a1e0911300035o532153b7qdc2ecd768200ce09@mail.gmail.com","threadId":"21793","inReplyTo":"7v4oocwh5o.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-30T08:35:22Z","receivedAt":"2009-11-30T08:35:22Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Nov 30, 2009 at 09:28, Junio C Hamano wrote:\n> Sverre Rabbelier writes:\n>> I don't think that's true, git.git currently does not have such a\n>> structure (everything is just dumped in the root directory). The only\n>> reason git_remote_helpers exists is to make it easier to create a\n>> python egg out of it and install that.\n>\n> If that is the case, shouldn't each of the helper written in Python need\n> to have a separate directory, not just a single git_remote_helpers\n> directory shared among them?\n\nI don't understand why that would be needed? The reason we added a\nsingle git_remote_helpers directory is because we wanted to share\ncommon code, having a single python package makes that easy.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"128753","messageId":"7vr5rgv1lr.fsf@alter.siamese.dyndns.org","threadId":"21793","inReplyTo":"fabb9a1e0911300035o532153b7qdc2ecd768200ce09@mail.gmail.com","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-30T08:49:36Z","receivedAt":"2009-11-30T08:49:36Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Sverre Rabbelier writes:\n\n> On Mon, Nov 30, 2009 at 09:28, Junio C Hamano wrote:\n>> Sverre Rabbelier writes:\n>>> I don't think that's true, git.git currently does not have such a\n>>> structure (everything is just dumped in the root directory). The only\n>>> reason git_remote_helpers exists is to make it easier to create a\n>>> python egg out of it and install that.\n>>\n>> If that is the case, shouldn't each of the helper written in Python need\n>> to have a separate directory, not just a single git_remote_helpers\n>> directory shared among them?\n>\n> I don't understand why that would be needed? The reason we added a\n> single git_remote_helpers directory is because we wanted to share\n> common code, having a single python package makes that easy.\n\nSorry, I don't understand that. With that reasoning, isn't having a\nsingle git package, be it python or not, even easier? Why would anybody\nwant a separate egg that includes everything that _happen_ to be written\nin Python in the first place? It doesn't make sense at all from packaging\npoint of view to me.\n\nA separate egg per remote-helper that you can pick and choose which ones\nto install and which ones to leave out would make perfect sense, exactly\nthe same way that distros already split git into \"git-core\", \"git-svn\",\netc., though. Your \"git-hg\" may consist of a single egg and perhaps some\nother supporting code, and people who want to convert away from legacy Hg\nrepository may want to install it, but it is entirely up to them if they\nalso want to install \"git-cvs\" that is implemented as a remote-helper that\nhappens to be written in Python, no?\n"},{"id":"128757","messageId":"fabb9a1e0911300156l7f8dbe55p7da26540b0360773@mail.gmail.com","threadId":"21793","inReplyTo":"7vr5rgv1lr.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Sverre Rabbelier","fromEmail":"srabbelier@gmail.com","sentAt":"2009-11-30T09:56:57Z","receivedAt":"2009-11-30T09:56:57Z","isPatch":true,"sender":{"key":"srabbelier@gmail.com","avatar":"https://avatars.githubusercontent.com/u/3098?v=4"},"body":"Heya,\n\nOn Mon, Nov 30, 2009 at 09:49, Junio C Hamano wrote:\n> Sorry, I don't understand that.  With that reasoning, isn't having a\n> single git package, be it python or not, even easier?  Why would anybody\n> want a separate egg that includes everything that _happen_ to be written\n> in Python in the first place?  It doesn't make sense at all from packaging\n> point of view to me.\n\nBecause that's the recommended way to create a python package, create\na new directory, put the files in it, and distribute it.\n\n> A separate egg per remote-helper that you can pick and choose which ones\n> to install and which ones to leave out would make perfect sense, exactly\n> the same way that distros already split git into \"git-core\", \"git-svn\",\n> etc., though.  Your \"git-hg\" may consist of a single egg and perhaps some\n> other supporting code, and people who want to convert away from legacy Hg\n> repository may want to install it, but it is entirely up to them if they\n> also want to install \"git-cvs\" that is implemented as a remote-helper that\n> happens to be written in Python, no?\n\nYes, fair enough, but we don't do that for any other files in git.git.\nThe packagers do so, sure, but a different concern. The reason we want\nto distribute the git_remote_helpers package is so that\ngit-remote-hg.py, which lives in git.git/ and is installed as\ngit-remote-hg can say \"from git_remote_helpers.hg import export\".\n\nThe only reason this is needed in the first place is because we can't\njust add the python files to libgit.a or embed it in git-remote-hg\nstatically, python does not support that. That is the only reason we\nneed to distribute the package, which is why we need a separate\ndirectory.\n\nThat is, if I've understood Johan's reasoning and intention correctly.\n\n-- \nCheers,\n\nSverre Rabbelier\n"},{"id":"128759","messageId":"200911301159.23383.johan@herland.net","threadId":"21793","inReplyTo":"fabb9a1e0911300156l7f8dbe55p7da26540b0360773@mail.gmail.com","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-11-30T10:59:23Z","receivedAt":"2009-11-30T10:59:23Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 30 November 2009, Sverre Rabbelier wrote:\n> Heya,\n> \n> On Mon, Nov 30, 2009 at 09:49, Junio C Hamano wrote:\n> > Sorry, I don't understand that. With that reasoning, isn't having a\n> > single git package, be it python or not, even easier? Why would\n> > anybody want a separate egg that includes everything that _happen_ to\n> > be written in Python in the first place? It doesn't make sense at all\n> > from packaging point of view to me.\n> \n> Because that's the recommended way to create a python package, create\n> a new directory, put the files in it, and distribute it.\n> \n> > A separate egg per remote-helper that you can pick and choose which\n> > ones to install and which ones to leave out would make perfect sense,\n> > exactly the same way that distros already split git into \"git-core\",\n> > \"git-svn\", etc., though. Your \"git-hg\" may consist of a single egg and\n> > perhaps some other supporting code, and people who want to convert away\n> > from legacy Hg repository may want to install it, but it is entirely up\n> > to them if they also want to install \"git-cvs\" that is implemented as a\n> > remote-helper that happens to be written in Python, no?\n> \n> Yes, fair enough, but we don't do that for any other files in git.git.\n> The packagers do so, sure, but a different concern. The reason we want\n> to distribute the git_remote_helpers package is so that\n> git-remote-hg.py, which lives in git.git/ and is installed as\n> git-remote-hg can say \"from git_remote_helpers.hg import export\".\n> \n> The only reason this is needed in the first place is because we can't\n> just add the python files to libgit.a or embed it in git-remote-hg\n> statically, python does not support that. That is the only reason we\n> need to distribute the package, which is why we need a separate\n> directory.\n> \n> That is, if I've understood Johan's reasoning and intention correctly.\n\nYes, you have. I'll repeat the history of this to hopefully clarify:\n\nI first created a \"git-remote-cvs.py\" script (originally under a different \nname, but that is not important), that was transformed (essentially copied) \nto \"git-remote-cvs\" by the build process. This script was large and \nunwieldy, however, and I found it more maintainable to split it into several \npython scripts. So I created a \"git_remote_cvs\", and put the supporting \nscripts in there.\n\nNow, in order for the smaller \"git-remote-cvs\" executable to do its job, it \nneeded to import the supporting scripts at runtime, so I decided to make a \npython egg from the \"git_remote_cvs\" subdir, that would be installed using \nPython's infrastructure. This, I deemed, was the safest way to ensure that \nthe \"git_remote_cvs\" scripts were always available at runtime.\n\nNext, Sverre started his \"git-remote-hg.py\" script, and found that he could \nre-use some of the scripts in the \"git_remote_cvs\" package. He therefore \n(with my blessing) refactored this subdir into the \"git_remote_helpers\" \nsubdir/package that is currently under discussion. Hence, this subdir is \nmeant to contain the support scripts for remote helper written in Python, \nboth common support scripts, and support scripts specific to each remote \nhelper. So far, only the common code is there, but we expect the Hg and CVS \nhelpers to add scripts to the \"hg\" and \"cvs\" subsubdirs, respectively.\n\nEND_OF_HISTORY\n\nJust to clarify, Git remote helpers does not live in the \n\"git_remote_helpers\" subdir. The subdir (which is installed as a Python \nlibrary package) does not contain anything resembling a complete remote \nhelper. Instead, the remote helper scripts live as regular scripts in the \ngit.git root dir, and (like any other git program) are turned into \nexecutables by the build process. The difference is that two of the remote \nhelpers currently being developed (Sverre's \"git-remote-hg\", and my \"git-\nremote-cvs\") are written in Python, and (want to) share some common \nsupporting code currently located in the \"git_remote_helpers\" subdir.\n\nWe _could_ split up the \"git_remote_helpers\" package into a \"git-remote-hg\"-\nspecific package, and a \"git-remote-cvs\"-specific package, but that would \nmean either having two copies of the current support code. Alternately, we \ncould create a _third_ package containing the common support code, that each \nof our hg/cvs support packages would in turn depend on. I don't think we \nwant to go there, at least not yet.\n\nAlso, to prevent this misunderstanding, we could create a \"python\" subdir in \ngit.git, and move the \"git_remote_helpers\" into there. However, it would \nslightly complicate (at least) the git-remote-cvs.py script which currently \nexploits the \"coincidence\" that the subdir has the same name as the \ncorresponding python package, and is therefore testable in both its unbuilt \nand built state.\n\n\nHope this helps,\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"128789","messageId":"7vvdgrordj.fsf@alter.siamese.dyndns.org","threadId":"21793","inReplyTo":"200911301159.23383.johan@herland.net","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-11-30T17:27:04Z","receivedAt":"2009-11-30T17:27:04Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johan Herland writes:\n\n> ... Hence, this subdir is \n> meant to contain the support scripts for remote helper written in Python, \n> both common support scripts, and support scripts specific to each remote \n> helper. So far, only the common code is there, but we expect the Hg and CVS \n> helpers to add scripts to the \"hg\" and \"cvs\" subsubdirs, respectively.\n\nAhh, Ok, that clarifies it. The packager (not me) can package what is\n(in|built from) remote_helpers directory into one package, and declare\nthat as a dependency to each of the individual remote helper packages that\nuses the common stuff found in there, if the distro wants to have \"one\nend-user feature per package\" granularity.\n\nJust to make sure you didn't misunderstand me, I wasn't complaining that\nthe directory was not further split for each helper. I wanted to know the\nreason behind wanting to have _one_ directory that is common across\nmultiple helpers that are supposed to be independent. \"A common library\"\nis a good reason to have that organization.\n\n> We _could_ split up the \"git_remote_helpers\" package into a \"git-remote-hg\"-\n> specific package, and a \"git-remote-cvs\"-specific package, but that would \n> mean either having two copies of the current support code. Alternately, we \n> could create a _third_ package containing the common support code, that each \n> of our hg/cvs support packages would in turn depend on. I don't think we \n> want to go there, at least not yet.\n\nI think that is typically done by the distros; in the longer term it would\nbe nicer to them if we did so in our build structure, but I do not think\nwe are there yet.\n\n> Also, to prevent this misunderstanding, we could create a \"python\" subdir in \n> git.git, and move the \"git_remote_helpers\" into there.\n\nIf (and this is a big if, as we are not migrating to Python) the use of\nPython proliferates over time, a single \"python\" subdir to hold \"a common\nlibrary\" to create the third package will not make sense in the longer\nterm, as different services written in Python will have different set of\ncommon supporting code, so there will be multiple common libraries and you\nwould need multiple third packages. You would probably need multiple\ndirectories there, perhaps as subdirectories of that single toplevel\ndirectory you called \"python\", so that scripts written in Python would say\n\"import pythonGit.remoteHelper\" or something like that.\n"},{"id":"128791","messageId":"200911301901.57652.johan@herland.net","threadId":"21793","inReplyTo":"7vvdgrordj.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-11-30T18:01:57Z","receivedAt":"2009-11-30T18:01:57Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 30 November 2009, Junio C Hamano wrote:\n> Johan Herland writes:\n> > We _could_ split up the \"git_remote_helpers\" package into a\n> > \"git-remote-hg\"- specific package, and a \"git-remote-cvs\"-specific\n> > package, but that would mean either having two copies of the\n> > current support code. Alternately, we could create a _third_\n> > package containing the common support code, that each of our hg/cvs\n> > support packages would in turn depend on. I don't think we want to\n> > go there, at least not yet.\n>\n> I think that is typically done by the distros; in the longer term it\n> would be nicer to them if we did so in our build structure, but I do\n> not think we are there yet.\n\nAgreed.\n\n> > Also, to prevent this misunderstanding, we could create a \"python\"\n> > subdir in git.git, and move the \"git_remote_helpers\" into there.\n>\n> If (and this is a big if, as we are not migrating to Python) the use\n> of Python proliferates over time, a single \"python\" subdir to hold \"a\n> common library\" to create the third package will not make sense in\n> the longer term, as different services written in Python will have\n> different set of common supporting code, so there will be multiple\n> common libraries and you would need multiple third packages. You\n> would probably need multiple directories there, perhaps as\n> subdirectories of that single toplevel directory you called \"python\",\n> so that scripts written in Python would say \"import\n> pythonGit.remoteHelper\" or something like that.\n\nYes, I agree that if we get multiple Python support packages, it makes \nsense to create a \"python\" subdir, and store each package as a \nsubsubdir of \"python\". Still, I don't think we need to plan that far \nahead now. We can do that restructuring when it becomes necessary. If \nthere are no more objections, I vote for keeping the current structure \nfor now.\n\n\nHave fun! :)\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"},{"id":"128792","messageId":"0OMCWm31DRbUGCfPIS6SSJn59HQIM9AKtSDgVSNdiSR99clfmJ3D-Q@cipher.nrlssc.navy.mil","threadId":"21793","inReplyTo":"20091130075221.GA5421@coredump.intra.peff.net","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Brandon Casey","fromEmail":"brandon.casey.ctr@nrlssc.navy.mil","sentAt":"2009-11-30T18:07:40Z","receivedAt":"2009-11-30T18:07:40Z","isPatch":true,"sender":{"key":"brandon.casey.ctr@nrlssc.navy.mil","avatar":null},"body":"Jeff King wrote:\n> Without this, test-lib checks that the git_remote_helpers\n> directory has been built. However, if we are building\n> without python, we will not have done anything at all in\n> that directory, and test-lib's sanity check will fail.\n> \n> Signed-off-by: Jeff King \n> ---\n> On top of sr/vcs-helper.\n> \n> This feels a little funny for NO_PYTHON to mean \"no remote helpers at\n> all\". But that is the way the Makefile is set up, since we seem to have\n> only python helpers.\n> \n> Makefile | 1 +\n> t/test-lib.sh | 2 +-\n> 2 files changed, 2 insertions(+), 1 deletions(-)\n> \n> diff --git a/Makefile b/Makefile\n> index 42744a4..443565e 100644\n> --- a/Makefile\n> +++ b/Makefile\n> @@ -1743,6 +1743,7 @@ GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS\n> \t@echo TAR=\\''$(subst ','\\'',$(subst ','\\'',$(TAR)))'\\' >>$@\n> \t@echo NO_CURL=\\''$(subst ','\\'',$(subst ','\\'',$(NO_CURL)))'\\' >>$@\n> \t@echo NO_PERL=\\''$(subst ','\\'',$(subst ','\\'',$(NO_PERL)))'\\' >>$@\n> +\t@echo NO_PYTHON=\\''$(subst ','\\'',$(subst ','\\'',$(NO_PYTHON)))'\\' >>$@\n> \n> ### Detect Tck/Tk interpreter path changes\n> ifndef NO_TCLTK\n> diff --git a/t/test-lib.sh b/t/test-lib.sh\n> index 4a40520..ca0839c 100644\n> --- a/t/test-lib.sh\n> +++ b/t/test-lib.sh\n> @@ -638,7 +638,7 @@ test -d ../templates/blt || {\n> \terror \"You haven't built things yet, have you?\"\n> }\n> \n> -if test -z \"$GIT_TEST_INSTALLED\"\n> +if test -z \"$GIT_TEST_INSTALLED\" && test -z \"$NO_PYTHON\"\n> then\n> \tGITPYTHONLIB=\"$(pwd)/../git_remote_helpers/build/lib\"\n> \texport GITPYTHONLIB\n\nShouldn't this section be moved down below the sourcing of ../GIT-BUILD-OPTIONS\non line 656 so that the value of NO_PYTHON will be available when running the\ntest scripts directly?\n\n-brandon\n\nps. There's something eerily familiar about this patch.\n"},{"id":"128807","messageId":"20091130205453.GA20348@coredump.intra.peff.net","threadId":"21793","inReplyTo":"0OMCWm31DRbUGCfPIS6SSJn59HQIM9AKtSDgVSNdiSR99clfmJ3D-Q@cipher.nrlssc.navy.mil","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-11-30T20:54:53Z","receivedAt":"2009-11-30T20:54:53Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Mon, Nov 30, 2009 at 12:07:40PM -0600, Brandon Casey wrote:\n\n> Shouldn't this section be moved down below the sourcing of ../GIT-BUILD-OPTIONS\n> on line 656 so that the value of NO_PYTHON will be available when running the\n> test scripts directly?\n\nOops, good catch. I stupidly tested with \"make NO_PYTHON=1 test\" instead\nof actually checking that GIT-BUILD-OPTIONS was propagating it\ncorrectly.\n\n> ps. There's something eerily familiar about this patch.\n\nHmmm. Yes, I didn't search before writing it, but you probably mean:\n\n http://article.gmane.org/gmane.comp.version-control.git/127172\n\nBut that is missing the NO-PYTHON bit in GIT-BUILD-OPTIONS (did you\nforget it there, or was it part of some other patch that also didn't get\napplied?).\n\nAlso, I am tempted to move the GIT-BUILD-OPTIONS invocation _up_. It\nis about reading config and should probably come before we start doing\n_anything_.\n\nSo maybe this instead:\n\n-- >8 --\nSubject: [PATCH] tests: handle NO_PYTHON setting\n\nWithout this, test-lib checks that the git_remote_helpers\ndirectory has been built. However, if we are building\nwithout python, we will not have done anything at all in\nthat directory, and test-lib's sanity check will fail.\n\nWe bump the inclusion of GIT-BUILD-OPTIONS further up in\ntest-lib; it contains configuration, and as such should be\nread before we do any checks (and in this particular case,\nwe need its value to do our check properly).\n\nSigned-off-by: Jeff King \n---\nI moved the BUILD-OPTIONS thing to just above the beginning of the\n\"have you built anything\" checks, but after all of the function\ndefinitions. But perhaps it should simply go at the very top of the\nscript. After all, in the case of \"make NO_PYTHON=1 test\", those\nvariables will already be defined at the very beginning of the script.\n\n Makefile | 1 +\n t/test-lib.sh | 6 +++---\n 2 files changed, 4 insertions(+), 3 deletions(-)\n\ndiff --git a/Makefile b/Makefile\nindex 42744a4..443565e 100644\n--- a/Makefile\n+++ b/Makefile\n@@ -1743,6 +1743,7 @@ GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS\n \t@echo TAR=\\''$(subst ','\\'',$(subst ','\\'',$(TAR)))'\\' >>$@\n \t@echo NO_CURL=\\''$(subst ','\\'',$(subst ','\\'',$(NO_CURL)))'\\' >>$@\n \t@echo NO_PERL=\\''$(subst ','\\'',$(subst ','\\'',$(NO_PERL)))'\\' >>$@\n+\t@echo NO_PYTHON=\\''$(subst ','\\'',$(subst ','\\'',$(NO_PYTHON)))'\\' >>$@\n \n ### Detect Tck/Tk interpreter path changes\n ifndef NO_TCLTK\ndiff --git a/t/test-lib.sh b/t/test-lib.sh\nindex 4a40520..2d523fe 100644\n--- a/t/test-lib.sh\n+++ b/t/test-lib.sh\n@@ -632,13 +632,15 @@ GIT_CONFIG_NOSYSTEM=1\n GIT_CONFIG_NOGLOBAL=1\n export PATH GIT_EXEC_PATH GIT_TEMPLATE_DIR GIT_CONFIG_NOSYSTEM GIT_CONFIG_NOGLOBAL\n \n+. ../GIT-BUILD-OPTIONS\n+\n GITPERLLIB=$(pwd)/../perl/blib/lib:$(pwd)/../perl/blib/arch/auto/Git\n export GITPERLLIB\n test -d ../templates/blt || {\n \terror \"You haven't built things yet, have you?\"\n }\n \n-if test -z \"$GIT_TEST_INSTALLED\"\n+if test -z \"$GIT_TEST_INSTALLED\" && test -z \"$NO_PYTHON\"\n then\n \tGITPYTHONLIB=\"$(pwd)/../git_remote_helpers/build/lib\"\n \texport GITPYTHONLIB\n@@ -653,8 +655,6 @@ if ! test -x ../test-chmtime; then\n \texit 1\n fi\n \n-. ../GIT-BUILD-OPTIONS\n-\n # Test repository\n test=\"trash directory.$(basename \"$0\" .sh)\"\n test -n \"$root\" && test=\"$root/$test\"\n-- \n1.6.6.rc0.327.gd49b\n"},{"id":"128809","messageId":"tzCtKYIbFlbIbn30IPnqgVxpN1o3NxDP88NXFHHufBYXMjZJIG1Gyw@cipher.nrlssc.navy.mil","threadId":"21793","inReplyTo":"20091130205453.GA20348@coredump.intra.peff.net","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Brandon Casey","fromEmail":"brandon.casey.ctr@nrlssc.navy.mil","sentAt":"2009-11-30T21:17:55Z","receivedAt":"2009-11-30T21:17:55Z","isPatch":true,"sender":{"key":"brandon.casey.ctr@nrlssc.navy.mil","avatar":null},"body":"Jeff King wrote:\n> On Mon, Nov 30, 2009 at 12:07:40PM -0600, Brandon Casey wrote:\n\n>> ps. There's something eerily familiar about this patch.\n> \n> Hmmm. Yes, I didn't search before writing it, but you probably mean:\n> \n> http://article.gmane.org/gmane.comp.version-control.git/127172\n\n:) yeah, that was it, nbd.\n\n> But that is missing the NO-PYTHON bit in GIT-BUILD-OPTIONS (did you\n> forget it there, or was it part of some other patch that also didn't get\n> applied?).\n\nIt was 1/2 of that series.\n\n> Also, I am tempted to move the GIT-BUILD-OPTIONS invocation _up_. It\n> is about reading config and should probably come before we start doing\n> _anything_.\n> \n> So maybe this instead:\n\n\n\nLooks fine to me.\n\nNo strong opinion on whether the BUILD-OPTIONS thing should be\nat the beginning of the script, or in the place where you placed\nit.\n\n-brandon\n"},{"id":"128814","messageId":"200911302331.41235.johan@herland.net","threadId":"21793","inReplyTo":"tzCtKYIbFlbIbn30IPnqgVxpN1o3NxDP88NXFHHufBYXMjZJIG1Gyw@cipher.nrlssc.navy.mil","subject":"Re: [PATCH] tests: handle NO_PYTHON setting","fromName":"Johan Herland","fromEmail":"johan@herland.net","sentAt":"2009-11-30T22:31:41Z","receivedAt":"2009-11-30T22:31:41Z","isPatch":true,"sender":{"key":"johan@herland.net","avatar":"https://avatars.githubusercontent.com/u/547031?v=4"},"body":"On Monday 30 November 2009, Brandon Casey wrote:\n> Jeff King wrote:\n> > On Mon, Nov 30, 2009 at 12:07:40PM -0600, Brandon Casey wrote:\n> >> ps. There's something eerily familiar about this patch.\n> >\n> > Hmmm. Yes, I didn't search before writing it, but you probably mean:\n> >\n> > http://article.gmane.org/gmane.comp.version-control.git/127172\n> >\n> :) yeah, that was it, nbd.\n\nOops. I got Brandon's patches in my local tree, but I never got around to \nresend the series until Sverre picked up and refactored it. Sorry for the \nscrewup.\n\n> > But that is missing the NO-PYTHON bit in GIT-BUILD-OPTIONS (did you\n> > forget it there, or was it part of some other patch that also didn't\n> > get applied?).\n> \n> It was 1/2 of that series.\n\nIndeed.\n\n> > Also, I am tempted to move the GIT-BUILD-OPTIONS invocation _up_. It\n> > is about reading config and should probably come before we start doing\n> > _anything_.\n> >\n> > So maybe this instead:\n> \n> \n> \n> Looks fine to me.\n\nAs with Brandon's original patch, this is of course\n\nAcked-by: Johan Herland \n\n> No strong opinion on whether the BUILD-OPTIONS thing should be\n> at the beginning of the script, or in the place where you placed\n> it.\n\nMe neither.\n\n\n...Johan\n\n-- \nJohan Herland, \nwww.herland.net\n"}]}