python-devel February 2019

python-devel@lists.fedoraproject.org

10 participants
13 discussions

Re: Python packages with extras dependencies
by Petr Viktorin 05 Feb '19

05 Feb '19

On 2/5/19 12:44 AM, Eli Young wrote: > Python packages can specify extras dependencies, which are sets of dependencies not required for core functionality, and which generally correspond to some feature. These can then be specified by downstream consumers of the package. For example, requests has an entry in extras called security[1], which currently adds requirements of python packages pyOpenSSL >= 0.14, cryptography >= 1.3.4, and idna >= 2.0.0. A downstream consumer that wants to use this would add a dependency on requests[security]. > > From what I can tell, the current practice in Fedora packaging is to ignore these. This simplifies packaging Python modules that have extras specified, but ultimately pushes the specification of those dependencies down into every consumer of the package, whether users or other packages. > > As an example of this, I currently maintain the python-dns-lexicon package, which provides a common CLI and API for various different DNS providers. Some of the providers have additional dependencies that are necessary to function, and which are specified as extras. The Plesk provider, for example, also requires python-xmltodict[2]. In line with what appears to standard practice, extra dependencies are not currently installed with the broader python-dns-lexicon package. If, however, a user or dependent package wants to utilize the Plesk functionality of python-dns-lexicon, they now need to know that python-xmltodict needs to be installed, and will need to check whenever the package updates as to whether or not that has changed. > > How should we be handling this? Right now, it seems that most packages follow this behavior of punting on the responsibility to package consumers. Should this continue? If not, how should we handle things? Should we just include all extras dependencies in the parent package? Alternatively, should we have dummy/meta subpackages for extras that require the parent package as well as any extras dependencies (e.g. python-dns-lexicon-plesk would require python-dns-lexicon and python-xmltodict)? > > [1]: https://github.com/requests/requests/blob/v2.21.0/setup.py#L105 > [2]: https://github.com/AnalogJ/lexicon/blob/v3.0.6/setup.py#L101 Hello, AFAIK, there are currently no official guidelines for Python extras, and there's some fame & glory waiting if you'd like to help draft them :) That said, I believe subpackages are the answer here. In addition you could use weak dependencies. I think the main package should have "Suggests:" for all the extras, and even "Recommends:" for ones that are almost always useful. I believe the cost of extra dependencies is lower in Fedora than on PyPI. Some common reasons for punting deps to extras don't apply (like bootstrapping issues or requiring compiled modules from pure-Python ones), so sometimes it's good to just go for hard Requires. Purely as a packager, I'd like to see "boolean Provides", something like: Provides: (python3dist(dns-lexicon[plesk]) if python3dist(xmltodict)) ... but at a chat with RPM devs on the last Flock, I learned that is not feasible. The Python SIG (python-devel(a)lists.fedoraproject.org) would be a good place to discuss specific details.

1 0

Re: Python packages with extras dependencies
by Miro Hrončok 05 Feb '19

05 Feb '19

On 05. 02. 19 0:44, Eli Young wrote: > Python packages can specify extras dependencies, which are sets of dependencies not required for core functionality, and which generally correspond to some feature. These can then be specified by downstream consumers of the package. For example, requests has an entry in extras called security[1], which currently adds requirements of python packages pyOpenSSL >= 0.14, cryptography >= 1.3.4, and idna >= 2.0.0. A downstream consumer that wants to use this would add a dependency on requests[security]. > > From what I can tell, the current practice in Fedora packaging is to ignore these. This simplifies packaging Python modules that have extras specified, but ultimately pushes the specification of those dependencies down into every consumer of the package, whether users or other packages. > > As an example of this, I currently maintain the python-dns-lexicon package, which provides a common CLI and API for various different DNS providers. Some of the providers have additional dependencies that are necessary to function, and which are specified as extras. The Plesk provider, for example, also requires python-xmltodict[2]. In line with what appears to standard practice, extra dependencies are not currently installed with the broader python-dns-lexicon package. If, however, a user or dependent package wants to utilize the Plesk functionality of python-dns-lexicon, they now need to know that python-xmltodict needs to be installed, and will need to check whenever the package updates as to whether or not that has changed. > > How should we be handling this? Right now, it seems that most packages follow this behavior of punting on the responsibility to package consumers. Should this continue? If not, how should we handle things? Should we just include all extras dependencies in the parent package? Alternatively, should we have dummy/meta subpackages for extras that require the parent package as well as any extras dependencies (e.g. python-dns-lexicon-plesk would require python-dns-lexicon and python-xmltodict)? This (metapackages) is what I've done in python-trimesh: https://src.fedoraproject.org/rpms/python-trimesh/blob/master/f/python-trim… https://src.fedoraproject.org/rpms/python-trimesh/blob/master/f/python-trim… I'd still consider this on case by case basis instead of developing a general solution, sometimes a simple Recommends works. Sometimes, it's more complicated. I'm CCing packaging and python to get more attention to this, but please keep the discussion on devel, so it's not shattered. > [1]: https://github.com/requests/requests/blob/v2.21.0/setup.py#L105 > [2]: https://github.com/AnalogJ/lexicon/blob/v3.0.6/setup.py#L101 -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

2 1

Re: python-pep8 is orphaned
by Miro Hrončok 02 Feb '19

02 Feb '19

On 29. 01. 19 5:07, iliana weller wrote: > Hello, > > I've orphaned python-pep8. pep8 was renamed to pycodestyle in 2016; it > received its last release in 2017. It should be removed from Fedora in a > future release. > > I unfortunately don't have time to proceed with the full retirement > process myself. If somebody would like to pick it up: > https://fedoraproject.org/wiki/Orphaned_package_that_need_new_maintainers#C… > > $ dnf repoquery --whatrequires python2-pep8 > python2-autopep8-0:1.2.4-9.fc29.noarch > python2-pytest-pep8-0:1.0.6-15.fc29.noarch > python2-spyder-0:3.3.1-3.fc29.noarch > $ dnf repoquery --whatrequires python3-pep8 > python3-autopep8-0:1.2.4-9.fc29.noarch > python3-hacking-0:1.1.0-3.fc29.noarch > python3-pytest-pep8-0:1.0.6-15.fc29.noarch > python3-spyder-0:3.3.1-3.fc29.noarch > > See also https://bugzilla.redhat.com/show_bug.cgi?id=1667200's dependent > bugs. I would like to see the package retired. python-autopep8, python-pytest-pep8, spyder, python-hacking: Would you mind switching to pycodestyle? $ dnf repoquery --repo=rawhide-source --whatrequires pythonX-pep8 (simplified) cachedir genbackupdata imgbased ovirt-guest-agent pylast python-actdiag python-autobahn python-blockdiag python-bloom python-cliapp python-f5-icontrol-rest python-nwdiag python-os-win python-ryu python-seqdiag python-shortuuid python-terminaltables python-ttystatus python-txaio syslog-ng Would you mind switching to pycodestyle or stop linting code on build time? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 3

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel February 2019