Python 3.7's Deterministic pycs
by Petr Viktorin
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
4 years, 4 months
Re: python-pep8 is orphaned
by Miro Hrončok
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...
>
> $ 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
4 years, 10 months
Re: Removal of Python 2 from the Xfce spin
by Miro Hrončok
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
4 years, 10 months
Need help on kickstarting my Open Source Contribution
by Rajeshkumar Pothiappan
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
4 years, 10 months
Re: [EPEL-devel] Re: Proposal for EPSCO: Python34 Moving to Python36
by Miro Hrončok
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....
[2]
https://src.fedoraproject.org/rpms/python-rpm-macros/blob/epel7/f/macros....
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
4 years, 10 months
Re: Removal of Python 2 from the Xfce spin
by Miro Hrončok
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
4 years, 10 months
Re: Removal of Python 2 from the Xfce spin
by Miro Hrončok
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
4 years, 10 months