Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[metadata] section of setup.cfg does nothing #466

Open
bmbouter opened this issue Apr 20, 2015 · 5 comments
Open

[metadata] section of setup.cfg does nothing #466

bmbouter opened this issue Apr 20, 2015 · 5 comments

Comments

@bmbouter
Copy link
Contributor

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?

@ask
Copy link
Contributor

ask commented Apr 21, 2015

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

@bmbouter
Copy link
Contributor Author

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?

@malinoff
Copy link
Contributor

@bmbouter python setup.py bdist_wheel

@ask
Copy link
Contributor

ask commented Apr 21, 2015

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.

@ionelmc
Copy link
Collaborator

ionelmc commented Apr 22, 2015

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.

@ask ask added this to the v4.1 milestone Jul 8, 2016
@auvipy auvipy modified the milestones: v4.1, 5.0 Jan 13, 2018
@auvipy auvipy modified the milestones: 5.0, 4.7 Aug 24, 2019
@auvipy auvipy assigned auvipy and unassigned ionelmc Aug 24, 2019
@auvipy auvipy modified the milestones: 5.1.0, 6.0 Sep 9, 2021
@auvipy auvipy modified the milestones: 6.0, 5.3 Apr 17, 2022
@auvipy auvipy modified the milestones: 5.3, 5.3.x Jun 17, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

5 participants