python-devel January 2019

python-devel@lists.fedoraproject.org

7 participants
7 discussions

Python 3.7's Deterministic pycs
by Petr Viktorin 15 Jul '19

15 Jul '19

Hello! The first beta for Python 3.7 is out. It will hopefully get into Fedora soon as python37. After it comes out of beta, we'll upgrade python3 to it. The What's New list is at: https://docs.python.org/3.7/whatsnew/3.7.html One thing that's interesting for packagers is PEP 552: Deterministic pycs: https://www.python.org/dev/peps/pep-0552/ Let me summarize in my own words. A new opt-in mode for byte-compilation makes .pyc (bytecode cache) files depend only on the contents of the corresponding source file. If we use this, it will slow down imports, because the whole source file would need to be read and hashed in order to verify if a .pyc file is valid. (Currently, metadata like the modification time and file size is used.) To speed things up, there's an option, UNCHECKED_HASH, which skips cache validation entirely. Using this would mean that if you modify a .py source file installed by RPM, the changes wouldn't take effect (the .py contents would only be shown in tracebacks). Modifying installed files in production is extremely bad practice, of course, but it's quite useful for debugging on throw-away systems. If we adopt UNCHECKED_HASH, anyone doing it will have to remember to remove the corresponding .pyc file. Honestly, I'm not sure we want to use this in Fedora. Is anyone here into reproducible builds, to make a better argument for this? -- Petr Viktorin

5 5

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

Re: Removal of Python 2 from the Xfce spin
by Miro Hrončok 29 Jan '19

29 Jan '19

On 09. 01. 19 9:34, Miro Hrončok wrote: > Hi, we've successfully removed Python 2 from default Workstation installation > years ago, today I'd like to see if we could do it in Xfce Spin as well. > > For those not in the picture: Python 2 ill EOL in 11 months, 22 days [0]. > We are trying to get rid of it as much as possible in Fedora [1][2]. > > Eliminating Python 2 from our defualt installations is an important step here. > > Today, if I try to uninstall python2 from Xfce spin (rawhide), this is what gets > removed as dependent: Here's an update: > NetworkManager-openconnect-gnome openconnect removed python2 dependency \o/ > blueberry still uses python2, Kevin, any chance you've checked why? Should I take a look? > gnumeric The Python 2 bits are only needed for Python 2 extensions, moved to a separate subpackage. > python2-catfish catfish now runs on python 3 \o/ > system-config-keyboard shall be removed form comps and replaced by xfce4-xkb-plugin > system-config-users ??? still looking for a solution ??? -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Need help on kickstarting my Open Source Contribution
by Rajeshkumar Pothiappan 27 Jan '19

27 Jan '19

Hi Fedora Python Team, I am a developer, I can code in Python. I am interested in contributing to Fedora as a Developer. I have read few guides/wiki. Still I need someone to guide atleast till I make my first contribution. Can some one please guide me.. ,With minimal guidance on 1. what to do 2. where to refer 3. Is any specific procedure to do that task, and many more. I need some mentor/guide to get started. Thanks in advance. by Rajeshkumar P

3 2

Re: [EPEL-devel] Re: Proposal for EPSCO: Python34 Moving to Python36
by Miro Hrončok 22 Jan '19

22 Jan '19

On 18. 11. 18 1:21, Orion Poplawski wrote: > On 11/15/18 10:08 AM, Stephen John Smoogen wrote: >> I missed this in the last meeting from items that needed to be voted on. >> >> The changes would be to make epel macros to have >> >> >> %python3_pkgversion 36 >> %python3_other_pkgversion 34 >> >> This should allow for the build system to rebuild python3 items as >> default. Then we will need a tracking ticket and bump/rebuild the >> packages > > Be aware that this will cause many current python34-* packages to disappear the > next time they are rebuilt for EPEL7. This was the plan from the beginning and as long as we inform all the interested parties (read: maintainers of such packages, users), we shall be good. EPEL "officials" need to decide whether to do it now, or align the change with the next RHEL 7.x release. As a Python Maintainer in Fedora and RHEL, I can say that we would very much like to see this happen and preferably sooner than later . We would like to add Python 3.6 to RHEL 7, but at this point we cannot make any promises. If we add it, it will most likely own /usr/bin/python3 and %__python3 will in all likelihood point to 3.6. We want to avoid as much breakage in EPEL as possible. Proposal: * We change macros.python3 [1] to 3.6. * We change macros.python3_other [2] to 3.4. * We rename the package to python-rpm-epel-macros (or whatever is the name convention) and the subpackages to python-srpm-epel-macros etc. In case python-rpm-macros comes to RHEL proper. Once (if) it does, we remove macros.python3 from the EPEL package. * We put this to all the announcement channels EPEL has. Caveat: If a packager needs to rebuild their package without changing the Python version, they need to invert the macros. This information needs to be part of the announcement. [1] https://src.fedoraproject.org/rpms/python-rpm-macros/blob/epel7/f/macros.py… [2] https://src.fedoraproject.org/rpms/python-rpm-macros/blob/epel7/f/macros.py… -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

Re: Removal of Python 2 from the Xfce spin
by Miro Hrončok 13 Jan '19

13 Jan '19

On 09. 01. 19 10:31, Zbigniew Jędrzejewski-Szmek wrote: > On Wed, Jan 09, 2019 at 09:34:54AM +0100, Miro Hrončok wrote: >> Today, if I try to uninstall python2 from Xfce spin (rawhide), this is what >> gets removed as dependent: >> >> NetworkManager-openconnect-gnome >> blueberry >> gnumeric >> python2-catfish >> system-config-keyboard >> system-config-users >> >> Several others go as no longer needed, mostly python2 libs, but also: >> >> NetworkManager-openconnect >> bluez-obex >> bluez-tools >> openconnect >> wmctrl >> >> While I doubt the actual usefulness of gnumeric, what bothers me is: > Maybe drop gnumeric, at least from the default installation? I really > liked gnumeric, it is lightweight and well designed, but its time seems > to have passed. I don't think we're doing anybody any favours by > encouraging people to use it. Exactly. >> 1. It seems that the Bluetooth stack is entirely gone. Do we have an viable >> alternative? > Hmm, in F29 workstation, I have bluez-obexd.x86_64 installed, and > "sudo dnf remove python2" doesn't touch it. What is the dependency > chain that you see? bluez-obexd was only removed as it was no longer required. The primary thing that got blasted by py2 removal was blueberry. >> 2. If openconnect is not needed on Workstation, why is it needed in Xfce? >> >> 3. Can we set keyboards/users with some alternatives? system-config-* still >> link to fedorahosted as upstream and haven't received an update in years. >> They seem pretty upstream dead to me. > >> 4. Catfish is Python 3 compatible, but the Fedora maintainer is not [4]. > I rebuilt the package with your PR. I hope I won't get flamed to death ;) Well it's my commit, so maybe I will get flamed :D -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

3 5

Re: Removal of Python 2 from the Xfce spin
by Miro Hrončok 09 Jan '19

09 Jan '19

On 09. 01. 19 9:52, Johannes Lips wrote: > On 09/01/2019 09:34, Miro Hrončok wrote: >> Hi, we've successfully removed Python 2 from default Workstation installation >> years ago, today I'd like to see if we could do it in Xfce Spin as well. >> >> For those not in the picture: Python 2 ill EOL in 11 months, 22 days [0]. >> We are trying to get rid of it as much as possible in Fedora [1][2]. >> >> Eliminating Python 2 from our defualt installations is an important step here. >> >> Today, if I try to uninstall python2 from Xfce spin (rawhide), this is what >> gets removed as dependent: >> >> NetworkManager-openconnect-gnome >> blueberry >> gnumeric >> python2-catfish >> system-config-keyboard >> system-config-users >> >> Several others go as no longer needed, mostly python2 libs, but also: >> >> NetworkManager-openconnect >> bluez-obex >> bluez-tools >> openconnect >> wmctrl >> >> While I doubt the actual usefulness of gnumeric, what bothers me is: >> >> 1. It seems that the Bluetooth stack is entirely gone. Do we have an viable >> alternative? >> >> 2. If openconnect is not needed on Workstation, why is it needed in Xfce? >> >> 3. Can we set keyboards/users with some alternatives? system-config-* still >> link to fedorahosted as upstream and haven't received an update in years. They >> seem pretty upstream dead to me. >> >> 4. Catfish is Python 3 compatible, but the Fedora maintainer is not [4]. > We can just switch to the python3 package catfish-python3, should be good > enough, or? That package has bad usability, nobody wants to use the command "catfish-py3" instead of "catfish" or see "Catfish(py3)" in the menu. There is no point of having python3-catfish and python2-catfish. Yet the maintainer does not have the intention to fix their broken package. Zbyszek just merged my catfish commit, but I'm prepared for a revert from the maintainer. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

python-devel January 2019