kombu

kombu copied to clipboard

I've been looking over how the 3.0 release stream of kombu handles its dependencies, and I can't tell what the purpose of the metadata section of setup.cfg is. It has already been removed from the 4.0-dev and master branches. I believe it's related to wheel packaging, and potentially this 3.0.19 release note.

If I modify setup.cfg to declare a package that doesn't exist I expect that when I install it it would fail saying it can't resolve a dependency. Instead it happily installs through all methods I know of including running these in the modified checkout folder:

sudo pip install .
sudo python setup.py install

This is true both with and without d2to1 installed in pip. What is the purpose of this [metadata] section? Should it still be here?

It's for wheel. It needs it to install importlib and ordereddict on Python 2.6

After talking with @ionelmc I suspected that it is for wheel, and I understand why ordereddict needs to install it in Python 2.6.

@ask What I don't understand is when this is used exactly? In the generation of a wheel? How can I do this myself. What commands are used to build the wheel?

@bmbouter python setup.py bdist_wheel

I don't know much about wheel so far, but the universal flag means that the same wheel package can be used for all python versions and platforms. The alternative is having one wheel for every platform/python version like would be required for something containing binaries (e.g. librabbitmq).

At first the wheel would not work on Python 2.6, as the wheel was generated using setup.py on Python 2.7 which does not include these dependencies.

The solution is not very satisfactory since it means we need to specify the dependencies in yet another location. We have bdist_rpm for RedHat in setup.cfg, metadata in setup.cfg for wheel, and then we have the requirements directory for everything else (setup.py reads from these files).

I think there was a PEP for a static metadata format for dependencies, which maybe this is based on or inspired from, so it would be great if there was a single location for this info.

Wheels do support conditional dependencies, we could have a fix like this https://bitbucket.org/pytest-dev/pytest/pull-request/269/add-support-for-building-proper-wheels/diff

I'll take a stab at this in few days, if no one wants to do it.