python-devel December 2019

python-devel@lists.fedoraproject.org

6 participants
9 discussions

Self-introduction
by Fabian Affolter 06 May '20

06 May '20

Hi all, I don't want to repeat myself, please take a look at my wiki page [1]. Why I want to join? I have one too many Python package and I started to add the python-sig as admin. But it goes both ways, if the SIG has access to my packages I want to be part of the SIG. My name is in the member list [2] for quite a while but I guess that doesn't come with the right permissions. Thanks for adding me to python-sig. If you have any further questions please replay to this message or write me in private. These days I'm no longer very active on IRC because of my day job. Kind regard, Fabian [1] https://fedoraproject.org/wiki/User:Fab [2] https://fedoraproject.org/wiki/SIGs/Python/Members_list

3 3

Re: Pagure for EL8 (EPEL8)
by Neal Gompa 25 Mar '20

25 Mar '20

On Mon, Nov 18, 2019 at 11:18 AM Kevin Fenzi <kevin(a)scrye.com> wrote: > > On Sat, Nov 16, 2019 at 05:37:16PM -0500, Neal Gompa wrote: > > I've done an early build locally to determine what's needed to make > > this possible. The following report from DNF indicates the missing > > packages that need to be added to EPEL 8 before I can introduce Pagure > > into EPEL8: > > > > Problem 1: conflicting requests > > - nothing provides python3-jenkins needed by pagure-ci-5.8-1.el8.noarch > > Problem 2: conflicting requests > > - nothing provides gitolite3 needed by pagure-5.8-1.el8.noarch > > - nothing provides python3.6dist(binaryornot) needed by > > pagure-5.8-1.el8.noarch > > - nothing provides python3.6dist(celery) needed by pagure-5.8-1.el8.noarch > > - nothing provides python3.6dist(flask-wtf) needed by pagure-5.8-1.el8.noarch > > - nothing provides python3.6dist(redis) needed by pagure-5.8-1.el8.noarch > > - nothing provides python3.6dist(straight.plugin) needed by > > pagure-5.8-1.el8.noarch > > - nothing provides python3.6dist(wtforms) needed by pagure-5.8-1.el8.noarch > > - nothing provides python3.6dist(pygit2) >= 0.26.0 needed by > > pagure-5.8-1.el8.noarch > > Problem 3: conflicting requests > > - nothing provides python3-trololio needed by pagure-ev-5.8-1.el8.noarch > > > > One of the reasons I'd like to have this done sooner rather than later > > is so that we can drop Python 2 support from Pagure with version 6.0. > > I think it's quite reasonable to say that version 6.0 isn't going to > > happen until we can get our Pagure servers running on EL8 using Python > > 3. > > > > So now, I need some help making this happen. I already own trololio, > > and I'm going to make that available in EPEL 8 ASAP. Can anyone help > > with some of the other dependencies here? > > Can you give a list with maintainers? I'm not sure off hand how many of > those are maintained by me/infra-sig, but any I can I would be happy to > add in. There's a few that are in testing I think already... > Sure, here's a list so far (package: maintainer): * gitolite3: limb * python-jenkins: cottsay * python-binaryornot: pingou * python-celery: bowlofeggs * python-flask-wtf: pingou * python-redis: kevin * python-straight-plugin: pingou * python-wtforms: kumarpraveen * python-pygit2: pwalter * python-trololio: ngompa I've already got trololio going: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2019-6c443851dd -- 真実はいつも一つ！/ Always, there's only one truth!

1 3

update to spyder4
by Mukundan Ragavan 22 Dec '19

22 Dec '19

I am looking to update Spyder-IDE to version 4.x [0] on rawhide and ran into some issues. Spyder 4 introduces a few new dependencies are not yet available in Fedora or have been retired. These dependencies are qdarksuite, diff-match-patch and python-language-server. qdarksuite is not necessarily a problem. It depends on qtsass and helpdev. These three are fairly easily packaged [1]. diff-patch-match is already present in Fedora but has not been updated for sometime by the looks of it. Although I have not tested if the latest upstream version builds, I suspect this should not be a problem. python-language-server (pyls), on the other hand, may be a problem. pyls depends on several packages including jsonrpc-server, versioneer and backports.functools_lru_cache in the simple configuration. The first two packages are straightforward to build [1]. However, lru_cache seems to python2 only as far as I can tell. Furthermore, it was recently retired in Fedora for the exact same reason [2]. How do I proceed? Can the SIG give me some pointers on how I can move forward? Anyone has experience with packaging Pyls? Thanks. [0] https://github.com/spyder-ide/spyder/releases [1] https://copr.fedorainfracloud.org/coprs/nonamedotc/spyder4/packages/ [2] https://src.fedoraproject.org/rpms/python-backports-functools_lru_cache/c/1…

3 5

Removing %py[23]?_(install|build)_egg macros
by Miro Hrončok 13 Dec '19

13 Dec '19

Hello, I'd like to remove the following macros from rawhide: %py_build_egg %py2_build_egg %py3_build_egg %py_install_egg %py2_install_egg %py3_install_egg Nothing in Fedora uses them. I would also remove this page: https://docs.fedoraproject.org/en-US/packaging-guidelines/Python_Eggs/ https://fedoraproject.org/wiki/Packaging:Python_Eggs To my best knowledge, there are no packaged eggs in Fedora, and Python upstream has moved away from eggs long time ago. I'd like to focus on packaging wheels instead, via https://src.fedoraproject.org/rpms/pyproject-rpm-macros Thoughts? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Request for feedback: %pycached macro for %files section
by Miro Hrončok 12 Dec '19

12 Dec '19

Hello, we are considering to add a %pycached macro to be used in the %files section: https://src.fedoraproject.org/rpms/python-rpm-macros/pull-request/37 We'd like to receive feedback. We plan to add it to rawhide and backport it to all Fedoras + EPEL7+. Usage: %files ... %pycached %{python3_sitelib}/foo.py This will list: /usr/lib/python3.8/site-packages/foo.py /usr/lib/python3.8/site-packages/__pycache__/foo.cpython-38{,.opt-?}.pyc Assuming the Python 3 version is 3.8. The bytecode files are globbed, their presence is not checked. This will fail: %pycached %{python3_sitelib}/foo error: %pycached can only be used with paths explicitly ending with .py And so will any of this: %pycached %{python3_sitelib}/* %pycached %{python3_sitelib}/foo.* %pycached %{python3_sitelib}/foo.p? %pycached %{python3_sitelib}/foo.?y %pycached %{python3_sitelib}/foo.?? But this will work: %pycached %{python3_sitelib}/foo*.py And it will generate the following globs: /usr/lib/python3.8/site-packages/foo*.py /usr/lib/python3.8/site-packages/__pycache__/foo*.cpython-38{,.opt-?}.pyc When used with paths that include Python 3 version, it globs with the version: %pycached /opt/python3.10/foo.py Generates: /opt/python3.10/foo.py /opt/python3.10/__pycache__/foo.cpython-310{,.opt-?}.pyc While paths without version have less strict globs: %pycached /custom/foo.py /custom/foo.py /custom/__pycache__/foo.cpython-3*{,.opt-?}.pyc This will generate a warning in RPM build: warning: File listed twice: /custom/__pycache__/foo.cpython-38.opt-1.pyc However it ensures the optimized bytecode is there. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Is retrace.fedoraproject.org useless for Python exceptions?
by Felix Schwarz 11 Dec '19

11 Dec '19

I'm wondering if there is a way to get the Python exception message via retrace/abrt? From what I can see the web interface only shows the call stack but without a specific exception there is not much I can do. (I saw the exception message when a user created a bugzilla bug) Example: https://retrace.fedoraproject.org/faf/reports/2609546/ thanks, Felix

2 3

Re: [EPEL-devel] Re: Python 3.7 in EPEL?
by Miro Hrončok 11 Dec '19

11 Dec '19

On 11. 12. 19 17:01, Stephen John Smoogen wrote: > On Tue, 10 Dec 2019 at 20:24, Miro Hrončok <mhroncok(a)redhat.com> wrote: >> >> Hey EPEL people. >> >> We got a request to branch Python 3.7 foe EPEL 7: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1781940 >> >> Are there volunteers to make that effort? And if so, should this be done in EPEL >> 8 first? And what about Python 3.8 in EPEL 7? >> >> So many questions. So little time. >> >> That said. If somebody want this, we (Python Maint) can help coordinate, but we >> don't have the manpower to really maintain various Python versions in EPEL for >> next X years. >> > > Honestly after all the work and pain it got to get python36 in > EPEL7... I would prefer not to try that again. Note that there is a big difference between maintaining a stack of various python37-foo packages and maintaining the interpreter only. > I think maintaining the > version that is the base in RHEL-8 is going to be more than enough > headaches and trying to keep up with the python of the year is not > productive. I think that any volunteers should first make the versions > of python37/38 in COPR and see if they have the volunteers and time to > maintain it there. That is true. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Python 3.7 in EPEL?
by Miro Hrončok 10 Dec '19

10 Dec '19

Hey EPEL people. We got a request to branch Python 3.7 foe EPEL 7: https://bugzilla.redhat.com/show_bug.cgi?id=1781940 Are there volunteers to make that effort? And if so, should this be done in EPEL 8 first? And what about Python 3.8 in EPEL 7? So many questions. So little time. That said. If somebody want this, we (Python Maint) can help coordinate, but we don't have the manpower to really maintain various Python versions in EPEL for next X years. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Should we discontinue the Python Classroom Lab?
by Miro Hrončok 05 Dec '19

05 Dec '19

Hello, I'd like to know whether it makes sense to continue maintaining and producing the Fedora Python Classroom Lab. It has problems: - no issue tracker, I don't even know if there are users with issues - there has simple been close to zero feedback, maybe nobody uses this? - the website is horribly outdated: https://pagure.io/fedora-websites/issue/962 - some Fedora versions weren't built: - I wasn't notified when F29 wasn't built - there was no way to get it fixed ex-post - https://pagure.io/releng/issue/7922 - Docker is broken - one of the main ideas was to produce a Docker image - the Docker instructions on the download page [4] are not working - not even when replaced with podman - I have no idea how to fix it - I know no way to upload to official dockerhub [5] - Vagrant experience is not good enough - one of the main ideas was to produce a Vagrant box/image - I know no way to upload to official Vagrant thing [6] - downloading the box manually is tedious The absolute lack of feedback makes is hard to dedicate time to actually persuade and fix the problems. [1] https://labs.fedoraproject.org/en/python-classroom/ [2] https://fedoramagazine.org/introducing-python-classroom-lab/ [3] https://fedoraproject.org/wiki/Changes/PythonClassroomLab [4] https://labs.fedoraproject.org/en/python-classroom/download/ [5] https://hub.docker.com/_/fedora/ [6] https://app.vagrantup.com/fedora/ -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel December 2019