Package installs as version 0.0.0 since the 4.0.0 release (yocto)

[dtoubelis]

There is a multitude of packages that declare a dependency on s specific version of configparser (i.e. 'configparser>=3.5'). Removing version form setup.cfg makes them think that configparser has version 0.0.0 and fail the version check. This problem has started a few days ago presumably with version 4.0.1.

Please restore the version attribute ASAP!!!

[jaraco]

Hi Dmitry. It's true, in 4.0, I converted the project to use setuptools_scm to derive the version from a single source, and it works like a charm:

configparser master $ git clean -fdx                                                                                                         
configparser master $ python setup.py --version                                                                                              
4.0.2.dev6+gaf80df1

Similarly, installing from PyPI using pip:

$ pip-run -q 'configparser>=4.0' -- -c "import importlib_metadata; print(importlib_metadata.version('configparser'))"    
4.0.1

Similarly, installing from source using pip:

$ pip-run -q --no-binary :all: 'configparser>=4.0' -- -c "import importlib_metadata; print(importlib_metadata.version('configparser'))"                                                                                                         
4.0.1

If the version is rendering as 0.0.0, that's probably because something else is going on to prevent setuptools_scm from being loaded... or you're installing from an unsupported source without the version info or metadata.

The release was made as a 4.0 release to indicate that some use-cases may not be supported. Although I'm not certain exactly which scenarios that might be, I've used this technique in packages for many years, so it should be stable even on older Pythons and build environments.

Can you describe a little bit more about the conditions under which this behavior occurs? Can you pin to <4.0 for now to mitigate the issue?

I'd like not to restore the version attribute as it adds complexity to the release process, varying from the technique I've developed for other packages, and increasing the chance for error.

This release is not particularly important, so I'll pull the 4.0 and 4.0.1 releases for now to limit the impact, but I'd like to work with you to figure out how to avoid the 0.0.0 version number so the issues don't recur with the 4.0.2 release.

[jaraco]

I've pulled 4.0.1 and 4.0.0 for now while we investigate.

[dtoubelis]

Your package is a transitive dependency that is used some other packages. We do not pull it directly. We build our OS image using youcto and setuptools is the only supported way, so no pip. I identified several dependencies that fail with the same error but since the build stops at first failure I cannot list them all. The one I was using for investigation is clickclick but there are at least 2-3 others. I'm not sure if it helpful or not but this is log from the build system:

| Traceback (most recent call last):
|   File "setup.py", line 156, in <module>
|     setup_package()
|   File "setup.py", line 151, in setup_package
|     entry_points={'console_scripts': CONSOLE_SCRIPTS},
|   File "/srv/yocto/build/platforms/amd64/tmp/sysroots/x86_64-linux/usr/lib/python2.7/distutils/core.py", line 111, in setup
|     _setup_distribution = dist = klass(attrs)
|   File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 316, in __init__
|   File "build/bdist.linux-x86_64/egg/setuptools/dist.py", line 371, in fetch_build_eggs
|   File "build/bdist.linux-x86_64/egg/pkg_resources/__init__.py", line 854, in resolve
| pkg_resources.ContextualVersionConflict: (configparser 0.0.0 (/srv/yocto/build/platforms/amd64/tmp/work/corei7-64-poky-linux/python-clickclick/1.2.2-r0/clickclick-1.2.2/.eggs/configparser-0.0.0-py2.7.egg), Requirement.parse('configparser>=3.5'), set(['entrypoints']))

This code did compile 2 days ago.

[jaraco]

What version of setuptools are you using? Can you upgrade setuptools before installing your packages? FYI, if you had installed using a late version of pip, your setuptools would have been updated for you.

[dtoubelis]

The version setuptools is tied to the version of yocto and we are currently using setuptools_33.1.1 and setuptools-scm_1.11.1. It is very hard to change versions without breaking something else, we build a few hundred python packages in our image and re-validating them all is huge amount of work.

[jaraco]

While investigating, I'm surprised that the package installs under setuptools 33.1.1. When I try to use setuptools prior to 34.4.0 to install, I get an error because py_modules isn't properly supported (another setup.cfg setting); I get this output.

Do you by chance have a docker image that includes yocto such that I could replicate your findings?

[dtoubelis]

Yocto is quite a massive project, so I don't think it is easy to reproduce it. I've just discovered that the native version of setuptools in yocto-2.2.4 is 22.0.5 and the version we are using is our custom upgrade. It is a good sign and it means upgrading setuptools may be manageable after all. So, I've already upgraded setuptools/setuptools_scm to the latest version and running the build right now. It takes about 2 hours to complete. I will have more information after that and we can try if upgrading setuptools solves this problem.

[dtoubelis]

BTW, after you downgraded version to 4.0.0 the build that was previously failing has passed. So, it definitely confirmes the root cause.

[prometheanfire]

https://doughellmann.com/blog/2016/02/25/so-youve-released-a-broken-package-to-pypi-what-do-you-do-now/

[samuelallan72]

@jaraco Please don't pull packages off pypi unless there's a very strong reason (eg. compromised code). This is breaking recent deployments of edx-platform. :(