VersionConflict when pip installing

[astrofrog]

On RTD, I've seen the following error - when RTD installs dependencies it does pip install -r requirements.txt and requirements for pyregion are:

numpy
matplotlib
Cython
astropy-helpers
astropy
wcsaxes

The last one is an affiliated package. RTD then crashes with the following error:

Downloading/unpacking wcsaxes (from -r docs/rtd-pip-requirements (line 6))
  Running setup.py (path:/var/build/user_builds/pyregion/envs/latest/build/wcsaxes/setup.py) egg_info for package wcsaxes
    Traceback (most recent call last):
      File "<string>", line 17, in <module>
      File "/var/build/user_builds/pyregion/envs/latest/build/wcsaxes/setup.py", line 8, in <module>
        import ah_bootstrap
      File "ah_bootstrap.py", line 530, in <module>
        _main()
      File "ah_bootstrap.py", line 527, in _main
        use_astropy_helpers(**kwargs)
      File "ah_bootstrap.py", line 198, in use_astropy_helpers
        upgrade = _do_upgrade(dist, index_url)
      File "ah_bootstrap.py", line 295, in _do_upgrade
        return _do_download(version=upgrade.version, index_url=index_url)
      File "ah_bootstrap.py", line 277, in _do_download
        raise Exception(msg.format(source, repr(e)))
    Exception: Error retrieving astropy helpers from https://pypi.python.org/simple:
    VersionConflict(astropy-helpers 0.4rc1.dev150 (/var/build/user_builds/pyregion/envs/latest/build/wcsaxes/astropy_helpers), Requirement.parse('astropy-helpers==0.4.3'))

I cannot reproduce this locally. @embray, do you have any idea what might be going on? The latest release of WCSAxes uses an older version of astropy-helpers than the one astropy uses but I wouldn't have thought that would matter?

[embray]

That's tricky. For what it's worth I fixed this problem a while ago in setuptools, but the fix was rolled back since it introduced another bug. I never had time to go back and fully fix it but I don't remember the details

https://bitbucket.org/pypa/setuptools/issue/141/setup_requires-feature-does-not-handle

Though is possible this is fixed by #45 ? If so the only thing to do is make sure to update WCSAxes, and older versions of WCSAxes with an older dependency of astropy-helpers will just be out of luck.

[embray]

(in any case, why is it bringing in a release candidate?)

[astrofrog]

I have no idea why it's bringing in a release candidate, this is what really puzzled me!

[embray]

Is it possible this is an issue with your environment? Did you install some old version of astropy_helpers into your site packages by accident?

[embray]

It appears that the copy of astropy_helpers included in the latest source distribution of wcsaxes on PyPI is in fact 0.4rc1.devsomethingorother, and the way it's set up a package will try to use the astropy_helpers it is bundled with first.

[embray]

And the fix for #45 didn't show up until astropy-helpers 0.4rc2 so that wcsaxes release wouldn't have it.

[astrofrog]

@embray - ah, I see! This was on RTD so maybe it was using an old version of setuptools. This all makes sense now, thanks! Closing since this is a solved problem :)

[embray]

I'm not sure it matters what version of setuptools you were using, because the workaround I added to astropy-helpers was meant to work around this issue on any version of setuptools. But for the workaround to work then of course your package needs to be bundled with some minimal version of astropy-helpers. It can't even auto-update the astropy-helpers on that old version because that's exactly where this problem occurs.

[astrofrog]

@embray - thanks for the clarification - this is not an issue, I'll just release a new version of WCSAxes with the latest astropy-helpers.