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
Dear python devel list,
I see that version of pyp2rpm packaged in Fedora 27 is older than
one from Fedora 26:
Fedora 28 3.3.0-3.fc28
Fedora 27 3.2.2-2.fc27
Fedora 26 3.2.3-1.fc26
Is there any reason for that?
see: https://apps.fedoraproject.org/packages/pyp2rpm/overview/
--
Martin Bukatovic
Hello,
Upstream I submitted a [change to PEP 394] to allow distributions to
change /usr/bin/python in some limited cases:
- Users and administrators can, by a deliberate action, change python to
invoke Python 3. (Activating a venv counts as such an action, but so
would e.g. using alternates, installing a non-default overriding
package, or replacing /usr/bin/python.)
- In controlled environments where being explicit is valued more than
user experience (test environments, build systems, etc.), distributions
can omit the python command even when python2 is installed.
If this goes through, in Fedora I would like to:
- Create a "python" package containing *just* the /usr/bin/python
symlink. This would be a subpackage of python2, and python2 would
*suggest* it. In other words, it would be installed by default with
Python 2, but mock, koji, and test tools would omit it (unless something
deliberately Requires `python` or `/usr/bin/python`).
- Put an unofficial "python 3.6" on COPR (and maybe eventually in a
Module), which would be the recommended way to make `python` invoke
Python 3.
[change to PEP 394]: https://github.com/python/peps/pull/630
Upstream post on python-dev:
https://mail.python.org/pipermail/python-dev/2018-April/153042.html
Let me know what you think.
Hi, see the deprecation notes for RHEL 7.5 [1]:
Python 2 has been deprecated
============================
Python 2 will be replaced with Python 3 in the next Red Hat Enterprise
Linux (RHEL) major release.
See the Conservative Python 3 Porting Guide [2] for information on how
to migrate large code bases to Python 3.
While this might have been obvious from the conditionals we have been
adding in some specfiles [3][4], this is AFAIK the first time this has
been publicly announced.
This is important for those who like to maintain a single spec for
everything. Previously, there have been messages on the devel list that
encouraged people to change the python3 conditional from "if fedora" to
"if fedora or rhel > 7" [5]. Please make a note that it will not be that
simple, because you'll also need to add conditionals for python2, see
for example already mentioned [3] or [4].
(If the conditionals are getting too complicated, consider not using
them at all and maintain multiple branches of the specs instead.)
This is also important for everybody who still runs their code on Python
2. Please consider to migrate ASAP. The Conservative Python 3 Porting
Guide [2] is very helpful. (I'm looking mostly at Fedora infra and QA here.)
We (Red Hat Python Maint and Fedora Python SIG) are happy to help. If
you feel lost, talk to us. Also, this is a reminder that we intend to
orphan Python 2 from Fedora [6] and so far nobody volunteered to
maintain it.
Python 2 will go upstream EOL in 1.75 years [7].
[1]
https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/7/ht…
[2] https://portingguide.readthedocs.io/en/latest/
[3]
https://src.fedoraproject.org/rpms/createrepo_c/pull-request/3#request_diff
[4]
https://src.fedoraproject.org/rpms/python-bugzilla/pull-request/2#request_d…
[5]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
[6]
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org…
[7] https://pythonclock.org/
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
I was reseraching a little bit and I found that this project is made in
python with Django. Is it possible that we can take this project and do an
implementation of our own?
The current implementation [1] is:
- Debian
- Postgres
- Django
- Python stack
And the stats (infrastructure requirements) [2] are:
- Storage:
- Application server:
- 1 GB General Purpose v1 Rackspace cloud server
- Number of user accounts: 6655
- Number of unique avatars: 6919 (355 MB)
- Static image server:
- 1 GB General Purpose v1 Rackspace cloud server
- Size of avatars on disk: 1.8 GB
- Traffic:
- Application server:
- Bandwidth: 328.31 MB
- Hits: 43,823
- Static image server:
- Bandwidth: 18.99 GB
- Total hits: 11,191,373
- Redirects (to Gravatar): 9,605,127
There is a long blog post [3] about why it's shutting down, but the link
that I found useful for possibly take this project is the development
environment [4].
It's just a question, maybe is too big to take it for the whole world, but
it looks like a great project for the Python SIG.
Br,
[1]
https://blog.libravatar.org/posts/Libravatar.org_is_shutting_down_on_2018-0…
[2] https://wiki.libravatar.org/shutdown-coordination
[3] https://feeding.cloud.geek.nz/posts/looking-back-on-starting-libravatar
[4] https://wiki.libravatar.org/development_environment
--
Eduard Lucena
Móvil: +56962318010
GNU/Linux User #589060
Ubuntu User #8749
Fedora Marketing Representative