I would like to structure my project such that when I build a wheel for deployment to PyPi, the wheel uses the pinned-down versions of dependencies, but during development/experimental builds uses the abstract/loosely-versioned dependencies.
I want developers to be able to use the abstract dependencies for experimenting with my package against other versions of the dependencies, but installs of my wheel from PyPi need to reference the concrete (pinned-down) dependencies with which my build system actually tested my wheel. Users that install my wheel from PyPi will not (and should not need to) have access to my package's requirements.txt. https://packaging.python.org/requirements/ talks about using `extras_require` (arg to `setup()` in setup.py) for the abstract or loosely-versioned dependencies, while placing the pinned-down or concrete dependencies in requirements.txt. However, when building a wheel, I don't see a way to build one that incorporates the pinned-down dependencies from requirements.txt instead of the loosely-versioned requirements from `extras_require`. For example: in setup.py: ``` setup( extras_require = { ":platform_system=='Linux' or platform_system=='Darwin'": ["pycapnp"] }, install_requires=[ "psutil>=1.0.1,<2" ], ... <other setup args> ) ``` and in requirements.txt: ``` pycapnp==0.5.8 ; platform_system=='Linux' or platform_system=='Darwin' psutil==1.0.1 ``` However, when I build my wheel via `python setup.py bdist_wheel`, the resulting wheel will reference only the abstract loosely-versioned dependencies from setup.py. `pip wheel -e .` appears to do the same. Thus, when users install my wheel from PyPi, the wrong versions of dependencies would be installed along with it instead of the pinned-down ones that I have in requirements.txt. Can anyone suggest a clean way to solve this? Man thanks, Vitaly
_______________________________________________ Wheel-builders mailing list [email protected] https://mail.python.org/mailman/listinfo/wheel-builders
