Tests assume that the git default branch is "master"

[pfmoore]

Description

My git config has "main" as the default branch (I don't know where this got set TBH)

❯ git config --get init.defaultbranch 
main

The following tests are failing:

FAILED tests/functional/test_install_vcs_git.py::test_git_install_branch_again_after_branch_changes - AssertionError: Script returned code: 1
FAILED tests/functional/test_install_vcs_git.py::test_install_git_branch_not_cached - AssertionError: Script returned code: 1
FAILED tests/functional/test_install_vcs_git.py::test_editable__no_revision - AssertionError: assert 'main' == 'master'

FAILED tests/functional/test_vcs_git.py::test_get_current_branch - AssertionError: assert 'main' == 'master'
FAILED tests/functional/test_vcs_git.py::test_resolve_commit_not_on_branch - AssertionError: Script returned code: 1

Expected behavior

Tests should not depend on the user's git configuration

pip version

Latest checkout from git, main branch (ironically :-))

Python version

3.9.4

OS

Windows 10

How to Reproduce

1. Configure git to default to the "main" branch
2. Then run the pip test suite
3. The above errors occur

Output

No response

Code of Conduct

• I agree to follow the PSF Code of Conduct.

[pfmoore]

I'm not sure how best to fix this, logging it as an issue so it doesn't get forgotten. I'm not sure if I'll have time to fix it myself, I can simply ignore these errors on my local machine for now.

[uranusjr]

Hmm, I can’t reproduce (at least your first one).

$ git config --add init.defaultbranch main  # This sets the config.
$ git config --get init.defaultbranch
main
$ tox -e py38 -- -k test_git_install_branch_again_after_branch_changes
[a ton of output]
===================== 1 passed, 2242 deselected, 116 warnings in 41.94s =====================
__________________________________________ summary __________________________________________
  py38: commands succeeded
  congratulations :)

There’s probably some Git magic we’re not getting right…

[pradyunsg]

I've had this set for a while, and the tests certainly work.

Did you set init.defaultbranch globally or just locally on a single repository (likely pip's)?

The output of the following will help confirm/eliminate this hypothesis:

git config --list --global
git config --list --local

[pfmoore]

It's set globally. Don't worry too much about it - if it's only happening for me, I'll try to work out what's odd with my config first. As I said, I can ignore those test failures for now.

[AbhinavOmprakash]

has something like this happened before? the tests fail on a local machine but pass during CI? I am experiencing something similar.
for e.g.

FAILED tests/functional/test_vcs_git.py::test_partial_clone - TypeError: CreateProcess() argument 8 must be str or None, not WindowsPath
FAILED tests/functional/test_vcs_git.py::test_partial_clone_without_server_support - TypeError: CreateProcess() argument 8 must be str or None,...
FAILED tests/functional/test_vcs_git.py::test_clone_without_partial_clone_support - TypeError: CreateProcess() argument 8 must be str or None....

maybe we could think about using docker for development if these issues occur more than a few times?

[pradyunsg]

maybe we could think about using docker for development if these issues occur more than a few times?

Very much not. pip runs on a variety of platforms. Pushing all of our development to docker would means everything else is a second class citizen, and I don't think we want that. I'd much rather we identify the issues of why these tests fail in some environments and fix that.

[AbhinavOmprakash]

okay, fair enough. makes sense

[ichard26]

@pfmoore have you ran into this issue again since opening this issue? It's been a while since I last tried to reproduce this, but I wasn't successful like the others as well. It's perplexing as AFAIU, the test harness does try to isolate git's configuration from the user's environment.

[ichard26]

Unless it turns out that @pfmoore is still running into this, I'm going to say this is no longer a concern. We haven't been able to reproduce the issue and things haven't broke broadly so yeah. LFTM.

[pfmoore]

Sorry I missed the previous question, no it's not been happening for a while, so agreed, it can be closed.