test_show_versions failing locally

[jbrockmendel]

>       assert re.search(r"commit\s*:\s[0-9a-f]{40}\n", result)
E       AssertionError: assert None
E        +  where None = <function search at 0x102703560>('commit\\s*:\\s[0-9a-f]{40}\\n', '\nINSTALLED VERSIONS\n------------------\ncommit           : None\npython           : 3.7.6.final.0\npython-bits     ...   : 0.14.1\nxlrd             : 1.2.0\nxlwt             : 1.3.0\nxlsxwriter       : 1.2.1\nnumba            : 0.47.0\n')
E        +    where <function search at 0x102703560> = re.search

[simonjayhawkins]

AFAIK the commit is None when the tests aren't run in the pandas directory.

[jbrockmendel]

it looks like the test fails if there are uncommited edits. i think in that case we can check that the pd.__version__ ends with ".dirty"

[simonjayhawkins]

it looks like the test fails if there are uncommited edits. i think in that case we can check that the pd.__version__ ends with ".dirty"

something else must be different. locally i'm seeing the commit hash on a dirty branch

>>> import pandas as pd
>>> pd.__version__
'1.1.0.dev0+530.g38e16c496.dirty'
>>> pd.show_versions()

INSTALLED VERSIONS
------------------
commit           : 38e16c496603b6c5ea69e830f7657b9f574c9967
python           : 3.7.6.final.0
python-bits      : 64
OS               : Windows
OS-release       : 10
machine          : AMD64
processor        : Intel64 Family 6 Model 58 Stepping 9, GenuineIntel
byteorder        : little
LC_ALL           : None
LANG             : en_GB.UTF-8
LOCALE           : None.None

pandas           : 1.1.0.dev0+530.g38e16c496.dirty
numpy            : 1.18.1
pytz             : 2019.3
dateutil         : 2.8.1
pip              : 20.0.2
setuptools       : 45.2.0.post20200209
Cython           : 0.29.15
pytest           : 5.3.5
hypothesis       : 5.5.4
sphinx           : 2.4.1
blosc            : None
feather          : None
xlsxwriter       : 1.2.7
lxml.etree       : 4.5.0
html5lib         : 1.0.1
pymysql          : None
psycopg2         : None
jinja2           : 2.11.1
IPython          : 7.12.0
pandas_datareader: None
bs4              : 4.8.2
bottleneck       : 1.3.1
fastparquet      : 0.3.3
gcsfs            : None
lxml.etree       : 4.5.0
matplotlib       : 3.1.3
numexpr          : 2.7.1
odfpy            : None
openpyxl         : 3.0.1
pandas_gbq       : None
pyarrow          : 0.16.0
pytables         : None
pytest           : 5.3.5
pyxlsb           : None
s3fs             : 0.4.0
scipy            : 1.3.1
sqlalchemy       : 1.3.13
tables           : 3.6.1
tabulate         : 0.8.6
xarray           : 0.15.0
xlrd             : 1.2.0
xlwt             : 1.3.0
xlsxwriter       : 1.2.7
numba            : 0.48.0
>>>

[jbrockmendel]

something else must be different. locally i'm seeing the commit hash on a dirty branch

hmm, could be an OSX thing. I just tried on Ubuntu and got the same behavior you did.

cc @WillAyd can you reproduce?

[WillAyd]

I see the commit hash as well on osx

INSTALLED VERSIONS
------------------
commit           : 80d37adcc3d9bfbbe17e8aa626d6b5873465ca98
python           : 3.7.6.final.0
python-bits      : 64
OS               : Darwin
OS-release       : 19.3.0
machine          : x86_64
processor        : i386
byteorder        : little
LC_ALL           : None
LANG             : en_US.UTF-8
LOCALE           : en_US.UTF-8

pandas           : 1.1.0.dev0+538.g80d37adcc
...

[jbrockmendel]

@WillAyd thanks for taking a look. This is getting funkier the more I look at it; might have to do with having a branch on a git worktree. Also now getting bad output on Ubuntu in some circumstances:

INSTALLED VERSIONS
------------------
{k:<17}: {stat}
{k:<17}: {stat}
{k:<17}: {stat}
[...]

[WillAyd]

IIRC there was an f-string issue that caused what you are seeing above. Thought already fixed on master - if not should be in the PR queue

[jbrockmendel]

OK good, tentatively looks like _print_versions.get_sys_info is implicitly assuming we are in the main branch of the git worktree

[jbrockmendel]

im inclined to think that the git check in get_sys_info should use the versioneer code in _version.py instead of trying to re-implement the logic