![](https://seccdn.libravatar.org/avatar/d07f42a0ce153005aa382400858c454a.jpg?s=120&d=mm&r=g)
Jason Craig <os-dev@jacraig.com> wrote:
On 04/01/2015 04:26 PM, Adam Spiers wrote:
Jason Craig <os-dev@jacraig.com> wrote:
Packages declare their dependencies in setup.py, so that is where py2pack looks for them, just like setuptools and pip.
But setup.py is just code, so it can invoke code in other files in order to determine the dependencies.
Is that a problem?
It is currently, because py2pack only parses setup.py. There is a pull request which fixes this: https://github.com/saschpe/py2pack/pull/9 It has been open since October 2013 :-/
As far as I understand it, a requirements file is more for developing a set of packages with versions known to work well in a certain configuration--e.g. if you are deploying a web application with a complex list of requirements that is only really tested with a specific set of versions of those requirements, something of that nature.
I think this behavior is by design.
If so, IMHO this design is broken because it excludes the pbr approach, and the OpenStack community is a significant contributor to the Python ecosystem:
Maybe the pbr approach is broken. I am rather fond of this post https://caremad.io/2013/07/setup-vs-requirement/ which explains why requirements.txt perhaps should be used differently than setup.py.
Very interesting, thanks for that link! It turns out that the post author is active in the OpenStack community and sent this to the pbr author (Monty Taylor, a.k.a. mordred) after writing it: 2013-07-23T08:17:55 <dstufft> Also this was partially inspired by you guys ;) https://caremad.io/blog/setup-vs-requirements/ /cc mordred -- http://eavesdrop.openstack.org/irclogs/%23openstack-infra/%23openstack-infra... The link to the corresponding Ruby post by Yehuda Katz is very enlightening. IIUC, this highlights a deficiency in the Python ecosystem's approach to packaging, due to the absence of any equivalent of Gemfile.lock. But yes, I am beginning to come round to the idea that maybe pbr's approach is broken. -- To unsubscribe, e-mail: opensuse-packaging+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-packaging+owner@opensuse.org