Re: [PATCH v7 2/2] json-writer: t0019: add Python unit test
- Date: Thu, 7 Jun 2018 01:16:14 +0100
- From: Ramsay Jones <ramsay@xxxxxxxxxxxxxxxxxxxx>
- Subject: Re: [PATCH v7 2/2] json-writer: t0019: add Python unit test
On 06/06/18 22:03, Jeff King wrote:
> On Wed, Jun 06, 2018 at 01:10:52PM -0400, Todd Zullinger wrote:
>> git@xxxxxxxxxxxxxxxxx wrote:
>>> +# As a sanity check, ask Python to parse our generated JSON. Let Python
>>> +# recursively dump the resulting dictionary in sorted order. Confirm that
>>> +# that matches our expectations.
>>> +test_expect_success PYTHON 'parse JSON using Python' '
>>> + python "$TEST_DIRECTORY"/t0019/parse_json_1.py <output.json >actual &&
>> Would this be better using $PYTHON_PATH rather than
>> hard-coding python as the command?
> Probably. We may want to go the same route as we did for perl in
> a0e0ec9f7d (t: provide a perl() function which uses $PERL_PATH,
> 2013-10-28) so that test writers don't have to remember this.
> That said, I wonder if it would be hard to simply do the python bits
> here in perl. This is the first use of python in our test scripts (and
Hmm, not quite the _first_ use:
$ git grep PYTHON_PATH -- t
t/lib-git-p4.sh: (cd / && "$PYTHON_PATH" -c 'import time; print(int(time.time()))')
t/lib-git-p4.sh: "$PYTHON_PATH" "$TRASH_DIRECTORY/marshal-dump.py"
t/t9020-remote-svn.sh:export PATH PYTHON_PATH GIT_BUILD_DIR
t/t9020-remote-svn.sh:exec "$PYTHON_PATH" "$GIT_BUILD_DIR/contrib/svn-fe/svnrdump_sim.py" "$@"
t/t9802-git-p4-filetype.sh: "$PYTHON_PATH" "$TRASH_DIRECTORY/k_smush.py" <"$cli/k-text-k" >cli-k-text-k-smush &&
t/t9802-git-p4-filetype.sh: "$PYTHON_PATH" "$TRASH_DIRECTORY/ko_smush.py" <"$cli/k-text-ko" >cli-k-text-ko-smush &&
t/t9802-git-p4-filetype.sh: "$PYTHON_PATH" "$TRASH_DIRECTORY/gendouble.py" >%double.png &&
t/t9810-git-p4-rcs.sh: "$PYTHON_PATH" "$TRASH_DIRECTORY/scrub_k.py" <"$git/$file" >"$scrub" &&
t/t9810-git-p4-rcs.sh: "$PYTHON_PATH" "$TRASH_DIRECTORY/scrub_ko.py" <"$git/$file" >"$scrub" &&
I don't run the p4 or svn tests, so ... :-D
> really the only user in the whole code base outside of a few fringe
> commands). Leaving aside any perl vs python flame-war, I think there's
> value in keeping the number of languages limited when there's not a
> compelling reason to do otherwise.
I agree that fewer languages is (generally) a good idea.