Upgrade fails due to inconsistent version

[dkav]

Describe the issue or bug
Upgrading rpy2 from 3.5.6 to 3.5.7 fails due to inconsistent version.

Discarding https://files.pythonhosted.org/packages/8b/39/4a9d9e59ba062f156a642af7271bed418584406a6e65c3a23d1ded8c4a77/rpy2-3.5.7.tar.gz (from https://pypi.org/simple/rpy2/) (requires-python:>=3.7): Requested rpy2 from https://files.pythonhosted.org/packages/8b/39/4a9d9e59ba062f156a642af7271bed418584406a6e65c3a23d1ded8c4a77/rpy2-3.5.7.tar.gz has inconsistent version: expected '3.5.7', but metadata has '3.5.6'

To Reproduce

pip install rpy2==3.5.6   
pip install rpy2 --upgrade

Expected behavior
rpy2 would upgrade.

Error
Relevant verbose output:

  writing manifest file '/private/var/folders/zn/l8w7w5pj55z3nqxjmg8zd3j40000gn/T/pip-modern-metadata-0_no_jsh/rpy2.egg-info/SOURCES.txt'
  creating '/private/var/folders/zn/l8w7w5pj55z3nqxjmg8zd3j40000gn/T/pip-modern-metadata-0_no_jsh/rpy2-3.5.6.dist-info'
  Preparing metadata (pyproject.toml) ... done
  Source in /private/var/folders/zn/l8w7w5pj55z3nqxjmg8zd3j40000gn/T/pip-install-kxuvgbrn/rpy2_4802b83590de45bd9ac76b610edb530c has version 3.5.6, which satisfies requirement rpy2 from https://files.pythonhosted.org/packages/8b/39/4a9d9e59ba062f156a642af7271bed418584406a6e65c3a23d1ded8c4a77/rpy2-3.5.7.tar.gz
  Removed rpy2 from https://files.pythonhosted.org/packages/8b/39/4a9d9e59ba062f156a642af7271bed418584406a6e65c3a23d1ded8c4a77/rpy2-3.5.7.tar.gz from build tracker '/private/var/folders/zn/l8w7w5pj55z3nqxjmg8zd3j40000gn/T/pip-build-tracker-0bb4uc1i'
Discarding https://files.pythonhosted.org/packages/8b/39/4a9d9e59ba062f156a642af7271bed418584406a6e65c3a23d1ded8c4a77/rpy2-3.5.7.tar.gz (from https://pypi.org/simple/rpy2/) (requires-python:>=3.7): Requested rpy2 from https://files.pythonhosted.org/packages/8b/39/4a9d9e59ba062f156a642af7271bed418584406a6e65c3a23d1ded8c4a77/rpy2-3.5.7.tar.gz has inconsistent version: expected '3.5.7', but metadata has '3.5.6'

Additional context

% python3 -m rpy2.situation
rpy2 version:
3.5.6
Python version:
3.10.9 (main, Dec 22 2022, 00:19:40) [Clang 12.0.0 (clang-1200.0.32.29)]
Looking for R's HOME:
    Environment variable R_HOME: None
    Calling `R RHOME`: /usr/local/Cellar/r/4.2.2_1/lib/R
    Environment variable R_LIBS_USER: None
R's additions to LD_LIBRARY_PATH:

R version:
    In the PATH: R version 4.2.2 (2022-10-31) -- "Innocent and Trusting"
    Loading R library from rpy2: OK
Additional directories to load R packages from:
None
C extension compilation:
  include:
  ['/usr/local/Cellar/r/4.2.2_1/lib/R/include']
  libraries:
  ['R', 'pcre2-8', 'lzma', 'bz2', 'z', 'icucore', 'dl', 'm', 'iconv']
  library_dirs:
  ['/usr/local/opt/gettext/lib', '/usr/local/opt/readline/lib', '/usr/local/opt/xz/lib', '/usr/local/lib', '/usr/local/opt/gettext/lib', '/usr/local/opt/readline/lib', '/usr/local/opt/xz/lib', '/usr/local/lib', '/usr/local/Cellar/r/4.2.2_1/lib/R/lib', '/usr/local/Cellar/pcre2/10.42/lib']
  extra_compile_args:
  []
  extra_link_args:
  []

[lgautier]

Thanks for the report. I cannot reproduce though.

Installing rpy2-3.5.6, and then pip install -U rpy2 upgrade to 3.5.7 without issue.

[dkav]

I tested some more but I have been unable to figure it out. Does it behave differently for you if you build from source (pip install -U --no-binary :all: rpy2)? The wheel does not work for my machine (MacOS 10.15) so pip is building from source.

[lgautier]

Binaries for Linux are currently not provided (although they might at some point - see #960). --no-binary should not have any influence.

Otherwise, the following ran successfully on my end:

pip uninstall rpy2  # until no rpy2 left
pip install --no-binary :all: rpy2==3.5.6
pip install -U --no-binary :all: rpy2

The issue is likely with either a pypi mirror your are using, or the use of a proxy or cache.

[dkav]

Thanks for looking into it. I will close the issue.

For full disclosure, my pip cache is disabled, no proxy is setup, and I am not using a mirror.

[dkav]

This issue reoccurred when updating from 3.5.7 to 3.5.8. It appears that the dynamic version number defined in pyproject.toml is coming from the existing install and not from the new package. I changed the version number in __init__.py in the site-packages folder to 0.0.0 and this is the result I got:

Requested rpy2 from https://files.pythonhosted.org/packages/a2/63/442160f69e1f163c24a73a3796b9ebd63c217b73941e4888734687e225d4/rpy2-3.5.8.tar.gz has inconsistent version: expected '3.5.8', but metadata has '0.0.0'

[lgautier]

I really cannot reproduce on this end, and so far this seems like the only report of an issue like this. Could it be that you have an outdated version of pip (or related elements in the install toolchain)?

[dkav]

Pip is up to date (23.0).

I left a question at pypa/setuptools#3819

[dkav]

I did a bit of sleuthing and found that this import statement is causing the problem:

rpy2/rpy2/situation.py

Line 25 in 4a4e600

import rpy2 # noqa:F401

Once I commented it out the issue did not arise.

[lgautier]

I see. PR #997 should fix the issue.

@dkav - Can you check that this is really fixing the issue on your end?

[dkav]

@lgautier local and testPyPI installs worked. 👍🏻

[lgautier]

Thanks.