Orphaned Python packages

[Michal Cyprian]

Hi,

I unfortunately won't have time to maintain these Python packages any longer:

  - python-afl (can be orphaned maybe)

  - pew @python-sig
 - python-rangehttpserver @python-sig
 - python-pythonz-bd @python-sig
 - python-resumable-urlretrieve @python-sig

I orphaned them, feel free to take them if you need/want them.

Michal Cyprian
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/XG2HCWIELAWOZESWOYEC6TDCW7P2CN56/

Ask for help with packaging of Pipenv deps

[Michal Cyprian]

Hi,

we added Pipenv, The higher level Python packaging tool [0], to Fedora recently.
It is a nice tool and it is also officially recommended from Python.org.
This is why we wanted to make it available to Fedora users as soon as possible.

The upstream Pipenv project contains a lot of bundled dependencies. Some of them
are not packaged for Fedora yet, so we were not able to unbundle them 
immediately.

The set of missing packages from PyPI is following:
* https://pypi.org/project/blindspin/
* https://pypi.org/project/delegator.py/
* https://pypi.org/project/first/
* https://pypi.org/project/pipreqs/
* https://pypi.org/project/pipdeptree/
* https://pypi.org/project/requirements-parser/
* https://pypi.org/project/shutilwhich/
* https://pypi.org/project/yarg/

In case you want to package some Python software for Fedora, we will appreciate 
your help.
Packages only for Python 3 version are needed. If you pick some of the 
packages, please respond
to this thread to prevent more packagers working on the same package. Also 
check if
the Review Request bug for the package doesn't exist already.
 
[0] https://src.fedoraproject.org/rpms/pipenv

Michal Cyprian
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org/message/HJPSR4AUMJGKLST22YYU3FGMQPHMSKQM/

Re: F27 Self Contained Change: Making sudo pip Safe (Again)

[Michal Cyprian]

There are plenty of bugs [0] reported by users, who break their 
systems using sudo pip and new bugs appear very often.
For example the bug [1] was opened a week ago. The biggest 
issue is that in the current state it is not easy or even possible 
to recover from such situations.
This issue is well known upstream as well, unfortunately there 
is not an elegant and simple solution to fix it for all the distributions.
Debian and its derivatives use [2] patch similar to our proposal for
Fedora since Python version 2.6.

This topic has been discussed many times on Fedora mailing lists, 
for example [3] and all the reasons why the Change is needed were 
described in detail. We believe this is a good first step on the way
to a safe Python environment.

I would also like to make clear some points discussed on the last
FESCo meeting [4]. This proposal was approved as a Change for F26.
However, some issues with the chosen implementation surfaced and there 
was not enough time for a proper investigation and fix of the problem
and so we decided to postpone it for F27.

The implementation was redesigned so the problems encountered previously
won't resurface. The main parts of the patch for F27 are similar 
to the Debian's fix, which was proved to work in many different contexts by now.

[0] https://www.google.cz/search?q="sudo+pip"+site%3Abugzilla.redhat.com
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1459244
[2] https://wiki.debian.org/Python
[3] 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/thread/3YXXX2ZPQTYG4675Y7G5VIM33HUEEPIM/#TDSIZ4XARHFOYXMS7ILMZIH4MDFGDR7P
[4] 
https://meetbot.fedoraproject.org/fedora-meeting/2017-06-09/fesco.2017-06-09-16.00.log.html

Michal Cyprian

- Original Message -
From: "Nico Kadel-Garcia" <nka...@gmail.com>
To: "Development discussions related to Fedora" <devel@lists.fedoraproject.org>
Sent: Thursday, June 1, 2017 12:07:16 PM
Subject: Re: F27 Self Contained Change: Making sudo pip Safe (Again)

On Wed, May 31, 2017 at 10:46 AM, Björn 'besser82' Esser
<besse...@fedoraproject.org> wrote:
> Am 31.05.2017 um 16:20 schrieb Jan Kurik:
>>
>> = Proposed Self Contained Change: Making sudo pip Safe (Again) =
>> https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
>>
>> Change owner(s):
>> * Michal Cyprian 
>> * Petr Viktorin 
>> * Tomas Orsava 
>> * Miro Hroncok 
>>
>>
>> At the present time, running sudo pip3 in Fedora is not safe. Pip
>> shares its installation directory with dnf, can remove dnf-managed
>> files and generally break the Python 3 interpreter. We propose a
>> series of measures that will make it safe to use.

>>  From the technical standpoint, this will be accomplished by changing
>> the install prefix setting of the distutils install command in the
>> /usr/bin/python3 executable from /usr/ to /usr/local. pip3 and
>> distutils will thereafter use this prefix when determining where to
>> install modules. In addition, the paths
>> /usr/local/lib/pythonX.Y/site-packages and
>> /usr/local/lib64/pythonX.Y/site-packages will be added to the front of
>> the sys.path variable so that modules are imported preferentially from
>> there. These settings, however, will not be modified for the
>> system-python binary, the /usr/bin/python3 executable when running
>> with -I option specified, nor when an RPM build is detected.
>> Therefore, Python RPM packages will continue to be built with the
>> correct installation path for system modules.

I wrote about this idea before: I'll re-iterate my concerns once, for
people new to the thread.

I still think it's a bad idea. What you're describing is essentially
reimplementing pyenv to point to /usr/local/, and automatically
activating that pyenv-like target as enabled by default for all users
of that system. It could, if engineered well, help avoid the
overwriting of RPM bundled components of precisely the same version
with pip installed versions, and vice versa. What it provides no help
with, because this shareable location will be activated by default
ahead of the more standard RPM bundled modules, is when newer versions
of modules installed by "pip3 install" are with existing modules of
any sort from any default discoverable location. The problem also
exists with pyvenv, but on a much smaller scale and only when the user
specifically selects to use that local installation. It remains very
difficult for older modules to include module dependencies to avoid
this, since at the time the older module was written the newer and
incompatible module may not have existed.

Been there, done that, with awscli and various Sphinx module versions
in the airflow modules dependency tree. With airflow, the Sphinx
upgrades broke quite a few previously working pip module
installations. An

What is your opinion on "sudo pip" fix for Fedora 27?

[Michal Cyprian]

At the present time, running sudo pip3 in Fedora is not safe.
Pip shares its installation directory with dnf, can remove 
dnf-managed files and generally break the Python 3 interpreter.

Our first attempt to make sudo pip safe on Fedora [0] was 
based on using a different binary (/usr/libexec/system-python) 
for RPM packaging purposes and changing the behavior 
of /usr/bin/python3 (and pip that uses its settings) to install 
under /usr/local by default. Switching all the Python 3 packages
to system-python turned out to be much more problematic than 
expected and we had to postpone the Change for F27.

We decided to try a different approach. The main idea is to detect
 an ongoing RPM build and modify the behavior of the Python 3
executable only when in normal user environment so that RPM builds 
won't be affected at all.

The adjustment of the behavior can be done on different levels.
The first option is to set the sys.prefix variable to /usr/local 
when the interpreter is initialized. This will affect
all the install methods, but the solution can cause some
problems in applications that rely on the value of sys.prefix.
A prototype of this implementation can be seen here [1].

The other possibility is to limit the pip install location change 
to distutils and pip [2]. This is the "safer" option, but does 
not cover all corner cases. For example, Python software built 
locally using cmake or similar tools will be installed into 
/usr/lib and can conflict with system tools. Debian chose to 
implement similar solution.

I would like to ask which solution would work for your applications 
better, and what is in your opinion the right way to go. I will
appreciate any costructive comments or ideas on how to improve these 
patches. If you want to check some specific use-case you can use the images
docker.io/mcyprian/sudo_pip_sys_prefix and 
docker.io/mcyprian/sudo_pip_install_prefix
to try out the two mentioned implementations.
 
[0] 
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe?rd=User:Torsava/Making_sudo_pip_safe
[1] 
https://github.com/mcyprian/python3/commit/6077c96460c03ddc334bae654fffcce44eb6873d
[2] 
https://github.com/mcyprian/python3/commit/ac2f266a90871d67ba8d0b70d2b0ebe47732f064

Michal Cyprian
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: pip install advice

[Michal Cyprian]

Hi,
unfortunately, we missed the deadline for F26 and we need to rework some
parts of the Change [0]. It is in progress at this moment. I believe,
we will make it for F27 and this issue will be finally fixed for all Fedora 
users.
The Change is Python 3 specific for now. You can find related discussions here 
[1] and [2].

[0] https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
[1] 
https://lists.fedoraproject.org/archives/list/python-de...@lists.fedoraproject.org/thread/3ZB2AZ77WN53E3XOB4AU7XKCJOJVHHHE/
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1421694

Michal Cyprian

- Original Message -
From: "Jeandet Alexis" <alexis.jean...@member.fsf.org>
To: devel@lists.fedoraproject.org
Sent: Friday, April 14, 2017 9:18:27 PM
Subject: Re: pip install advice

Le vendredi 14 avril 2017 à 13:35 -0500, Rex Dieter a écrit :
> Jeandet Alexis wrote:
> 
> > On many places users are advised to use "pip install" to install
> > python
> > packages.
> 
> ...
> > So my point is first, I think on ubuntu they install with pip on a
> > different folder than packaged python packages. Should Fedora do
> > something like this?
> 
> Like this?
> https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe
Yeah! Perfect, that's what I mean, I'm happy to see this.
I'm not sure this is/was Python3 specific.
At least that lead to a question like "why do we ship pip as is?".

My other point, is WTF they(continuum) say that anaconda is a good idea
on Linux? 
> 
> -- rex
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Alternative Python build tools issues

[Michal Cyprian]

After application of patches described in Making sudo pip safe
Fedora Change [0], unexpected issues in packages using
non-standard build methods/scripts appeared. We received 
bug reports for DNF [1] and Anaconda [2].

We decided to temporarily revert the main patch last 
Friday (2017-02-24) to prevent build failures and anaconda crashes
while we investigate what will need to change.

To simplify, the main reason for the build failures is that some
packages use /usr/bin/python3 (or $PATH/python3) instead of
%{__python3} when building RPMs. It's not always
trivial to fix this in build systems that hardcode assumptions
about where the python3 binary is.

I collected some data to have an idea how many
packages are affected.
The total number of Python 3 packages in 
Fedora according Fedora Porting Database [3] is 1837.

The most frequently used alternative build tools for Python 
packages are CMake (28 packages) and Autotools (133 packages).
8 out of 28 packages using CMake fail to build in Copr [4] 
as well as 12 out of 133 packages using Autotools [5].

These build tools need to be configured to use 
%{__python3} during rpm build. There are also some
custom build scripts not following best practices and 
hardcoding the path to the python executable or to 
python site-packages. Specific fixes will have to be done
 in these cases.

We'll meet with Anaconda developers to discuss the problem.

[0] 
https://fedoraproject.org/wiki/Changes/Making_sudo_pip_safe?rd=User:Torsava/Making_sudo_pip_safe/Making_sudo_pip_safe
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1426435
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1425827
[3] http://fedora.portingdb.xyz/
[4] https://copr.fedorainfracloud.org/coprs/mcyprian/cmake-pkgs/builds/
[5] https://copr.fedorainfracloud.org/coprs/mcyprian/autotools-pkgs/builds/

Michal Cyprian
___
python-devel mailing list -- python-devel@lists.fedoraproject.org
To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Making sudo pip Safe (Again)

[Michal Cyprian]

- Original Message -
From: "Adam Williamson" 
To: "Development discussions related to Fedora" 
Sent: Friday, January 20, 2017 6:12:33 PM
Subject: Re: F26 Self Contained Change: Making sudo pip Safe (Again)

...

>>  In addition, system-python—a
>> stripped down version of Python 3 for use by system tools—will not
>> read the sudo pip3 install location, making it more secure by being
>> less susceptible to interference by user-downloaded modules.
>> 
>> From the technical standpoint, this will be accomplished by changing
>> the sys.prefix setting in the /usr/bin/python3 executable from /usr/
>> to /usr/local. pip3 will thereafter use this prefix when determining
>> where to install modules.

> This seems like quite a significant change. Have you investigated any
> potential unexpected consequences of this? Do setuptools etc. use this
> setting in any way? Have you checked for existing code reading it for
> any reason? Have you checked what else Python itself uses it for, and
> if any of that could be negatively affected?

We have checked how the main python packages and libraries will be affected 
by this change. Whole environment including python3, system-python, setuptools, 
pip and virtualenv was tested and it works fine.

...

> Presumably this change is applied only to Python 3 because there is no
> 'system-python-2'?

Yes, this change will be applied only to Python 3.

-- 
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net

Change owners
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Making sudo pip Safe (Again)

[Michal Cyprian]

- Original Message -
From: "Jason L Tibbitts III" 
To: "Development discussions related to Fedora" 
Sent: Friday, January 20, 2017 6:33:36 PM
Subject: Re: F26 Self Contained Change: Making sudo pip Safe (Again)

> "JK" == Jan Kurik  writes:

> JK> We aim to move the working directory for sudo pip3 to a more
> JK> appropriate location: /usr/local/lib/pythonX.Y/site-packages, and
> JK> modify the Python 3 interpreter in Fedora to scan both above
> JK> mentioned locations when importing modules.

> I wanted to point out a potential caveat with using /usr/local for
> things; some sites manage things under there in ways you can't really
> predict.  For example, all of my machines used to rsync the entire
> /usr/local tree from a master host.  Before that, it was an NFS mount.

> However, I no longer do that and I don't think Fedora would ever
> actually ship anything under /usr/local besides the few directories that
> the filesystem package creates, so I'm certainly not going to object.  I
> did, however, want make sure folks were aware that we should be careful
> not to assume too much about the structure of /usr/local.

 - J<

Ruby on Fedora uses /usr/local/share/gems/ for packages installed as a root 
via gem tool for many years.

Sudo pip installed packages on Debian are stored under 
/usr/local/lib/pythonX.Y/site-packages. 
We consider their switch to dist-packages unnecessary.

Placing user-installed modules into /usr/local is compliant with 
the Filesystem Hierarchy Standard, as pip-installed modules are 
specific to the host and not part of the distribution.

Change owners
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 Self Contained Change: Making sudo pip Safe (Again)

[Michal Cyprian]

- Original Message -
From: "Richard Ryniker" 
To: devel-annou...@lists.fedoraproject.org
Cc: devel@lists.fedoraproject.org
Sent: Friday, January 20, 2017 5:23:43 PM
Subject: Re: F26 Self Contained Change: Making sudo pip Safe (Again)

>> System-python makes sense: a Python environment dedicated to system
>> activities which changes only in a controlled way (updates can be
>> tested against a suite of system activities before they are applied;
>> new Python releases and maintenance may be deferred indefinitely
>> unless they contain required function or fix a relevant problem.)

>> The activity of pip3 is a separate question, and the proposed change
>> does not discuss complications this may introduce.  Instead of a
>> change to Fedora's Python semantics, which may confuse users and
>> incurs continuing maintenance cost, would it not be better to convince
>> Python's upstream developers to address this issue for all Python
>> users and platforms?

It would. However, the problem doesn't affect Windows or Mac, and Debian/Ubuntu 
already solve this at the distro level. There's not much motivation for 
upstream 
to address the issue quickly.

>> If the wider community of Python users does not consider the value of
>> this enhancement to module search semantics worth its cost, instead of
>> Fedora-only changes to Python, perhaps Fedora could use Python's native
>> mechanisms (such as pip3) in its Python packages.  

>> I already have an embarrassment of Python riches on my system - Python
>> 2.7 and 3.5 from Fedora repositories, 3.6 from my local build, and
>> probably another 3.6 from Fedora in the near future.  The thought of
>> doubling the number of locations where modules might be installed
>> is... unsettling.

Integrating dnf and pip3 more closely, so that packages installed by one could 
be uninstalled/upgraded with the other, would certainly be an interesting 
project. 
However, it would also be a very big project. It's not feasible to do in any 
reasonable time.

>> I have a few Python applications that change sys.path, and suppose
>> many others do.  All of these have some potential to be confused by
>> the proposed Fedora change; most likely they ignore it, and thereby
>> can induce import failures.

Can you be more specific? Do you have applications that hardcode Fedora's 
module path (which would break), or just ones that add additional entries 
to the existing path (which would not break)? Or are they doing something else?

>> Even if Fedora "fixes" pip3, this cures only the most common
>> conflicts.  This may be good to do, but users with non-standard
>> installation procedures still may interfere with dnf-managed files.

If users have installation procedures that may interfere with dnf-managed files,
they are doing it wrong. This change is about not providing a convenient tool
that does things wrong when someone follows what's common practice on other 
systems (well, Ubuntu).

>> Instead of a patchwork of hacks to address individual cases such as
>> pip3, why not seek a general solution?  Perhaps a database of
>> checksums for dnf-managed files that a dnf utility could verify,
>> report errors, and restore from repositories when ordered to do so.

That could make a good feature request for DNF. This Change is about 
not overwriting DNF-installed files in the first place, not about checking 
system integrity.

We're trying to not make this a patchwork of hacks, but rather a set of 
configuration options plus upstream-bound patches to support that config. 
Unfortunately, we need this fix in Fedora faster than we can push it 
upstream (where we need to also consider Windows, etc), to prevent 
unsuspecting people from breaking their systems.

Our first plan was to find an upstream solution for this, we surveyed
many previous discussions and possibile solutions. However, this problem 
is too distro-specific for a global upstream change to happen in reasonable 
time frame. This Change we proposed seems to fix the problem and doesn't 
greatly diverge from upstream.

The /usr/local/.../site-packages directory will be shared between all 
pip-installed modules, whether installed using the packaged python3-pip, 
or installed by pip run on Python 3 (of the same version) compiled from 
source with the prefix /usr/local. This could be a problem if the user 
wants to pip install one version of a package for the packaged Python 3.x 
and a different version for the Python 3.x compiled from source. 
(Note that with different minor versions, e.g. 3.5 and 3.6, there are 
no problems as these have separate module directories.) However, this 
potential conflict is a small corner case compared to the number of 
users who accidentally break their system by running sudo pip. [0]

More precise description and disccusion related to this change 
can be found at python-devel mailing list thread [1]

[0] For example:
* https://bugzilla.redhat.com/show_bug.cgi?id=1396158
* 

Re: Making sudo pip Safe

[Michal Cyprian]

Thanks for all suggestions and comments. Debian's patch is very complex 
compared to our solution.
Our patch is 12 lines long including docstring and it doesn't break any tests. 
Behavior of 
/usr/bin/python3 executable with customized sys.prefix will be a bit similar to 
virtual environment 
created with option --system-site-packages. Early results of whole environment 
(system-python + patched python3) 
tests in mock are promising.

Something similar to this proposal:
> CFLAGS="%{optflags}" %{__system_python} %{py_setup} %{?py_setup_args} build
> --executable="%{__python3} %{py3_shbang_opts}" %{?*}

could help us to enable `sudo pip`-installed extensions of DNF-installed 
programs. 
Unfortunately --executable doesn't affect scripts listed as 'entry-points' in 
setup.py script. 
We will probably have to patch setuptools to make this work.

Michal Cyprian


- Original Message -
From: "Petr Viktorin" <pvikt...@redhat.com>
To: python-devel@lists.fedoraproject.org, "Michal Cyprian" <mcypr...@redhat.com>
Sent: Monday, December 12, 2016 11:57:23 AM
Subject: Re: Making sudo pip Safe

On 12/09/2016 06:09 PM, Orion Poplawski wrote:
> On 12/07/2016 05:53 AM, Michal Cyprian wrote:
>> Hello,
>>
>> there is a long-standing problem that `sudo pip install` cannot be safely 
>> used in Fedora. Many users don't know about this and break python packages 
>> on theirs systems. Packages installed using this command can conflict and 
>> overwrite Python rpm packages.
>> This is a major problem and we have seen several systems broken by people 
>> using "sudo pip". Unfortunately, telling people to not use it will not work: 
>> "sudo pip" appears in documentation of too many projects online.
>> We plan to solve this in Fedora 26. A more precise description of the 
>> problem follows.
>>
>> Current behavior of python packages installation tools in Fedora:
>> 1) sudo dnf install python3-foo  # root installs foo from rpm to 
>> /usr/lib/pythonX.Y/site-packages
>> 2) sudo pip3 install foo  # root installs foo from PyPI to 
>> /usr/lib/pythonX.Y/site-packages
>> 3) sudo pip3 install -t /usr/local/lib/pythonX.Y/site-packages foo  # root 
>> install package to selected location
>> 4) pip3 install --user foo # user install foo from PyPI to 
>> ~/.local/lib/python3.5/site-packages
>>
>> Using  the --user option with pip would be the ideal solution. However, it 
>> is reportedly broken in some versions of Ubuntu, so it is hard to convince 
>> software authors to recommend it.
>>
>> Packages installed using `sudo pip` (2) under /usr can be overwritten or 
>> removed by dnf. `dnf install python3-foo` fails if foo was `sudo pip 
>> installed` before etc. This problem has been reported many times. [6]
>> Another issue is that packages installed under usr/local (3) cannot be 
>> imported unless PYTHONPATH or sys.path is set explicitly.
>>
>> The default install location of pip/distutils-installed packages depends on 
>> the value of the
>>  sys.prefix variable [4].
>> There were several discussions on Bugzilla [1] and the pypa-dev mailing list 
>> [2].
>> Interesting solutions were conceived at the CPython level:
>> - addition of sys.local_prefix [2]
>> - simplification of CPython startup sequence [4]
>> Unfortunately none of them were realized and both solutions require many 
>> changes of Python and Python Standard Library.
>>
>> We discussed all the possible solutions with colleagues from the Python 
>> maint team.
>> It would be great to fix this upstream, but it won't happen in a reasonable 
>> time frame.
>> We realized that System Python [3], which was announced in Fedora 24, can 
>> help us reach the goal. We came up with the following solution:
>>   - sys.prefix of the python3 executable will be set to /usr/local
>>   - sys.prefix of system-python will be set to /usr
>>   - all rpm python packages will be installed using system-python (value of 
>> rpm macro %{__python3} will be changed to point to system-python)
>>   - The path /usr/lib/.../site_packages will be included in sys.path of 
>> /usr/bin/python3
>>
>> Note that no packages will be affected by other work going on around 
>> system-python, namely that packages can declare that they are only using a 
>> smaller subset of the Python stdlib. That option is still opt-in.
>>
>> Behavior of install methods after mentioned changes:
>> 1) sudo dnf install foo  # root installs foo from rpm to 
>> /usr/lib/pythonX.Y/site-packages
>> 2) sudo pip3 install foo  # root installs foo from PyPI to 
>> /usr/loc

Orphaning pypy's epel5 branch

[Michal Cyprian]

Hi,

We've decided to orphan epel5 branch of pypy package. There is pypy in version 
1.8 which is really outdated (current version is 5.3.1), it doesn't make sense 
to update it and the maintenance is quite difficult. 
I was not able to build it properly after application of fix for CVE-2016-0772 
python: smtplib StartTLS stripping attack.

Michal Cyprian
--
devel mailing list
devel@lists.fedoraproject.org
https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org

Self Introduction: Michal Cyprian

[Michal Cyprian]

Hi all,

I would like to introduce myself. My name is Michal Cyprian, I started to work 
as an Intern in Red Hat Brno. I have joined Python maintenance group here. I 
don't have many experience in free and open source project so far, but I am 
highly interested in this area and I believe, that there will be lots of them 
in my future. My first task was to learn how to create rpm packages of python 
sources.
You can see Review Request of my first package here: 
https://bugzilla.redhat.com/show_bug.cgi?id=1240634
I was packaging python module with really fascinating functionality. Python-afl 
is an experimental module that enables American fuzzy lop fork server and 
instrumentation for pure-Python code.

Best regards

Michal
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct