On Wed, Feb 10, 2016 at 5:38 AM, Petr Viktorin <pviktori@xxxxxxxxxx> wrote: > On 02/09/2016 08:26 PM, Zbigniew Jędrzejewski-Szmek wrote: > >> Second, why call it python-*, not python3-*? I think it'll >> be endlessly confusing to have both python*- (v3), python2-* (v2), >> and python3-* (v3) mixed in the same distro. > > The assumption is that the basic system tools can agree on a single, > system-wide version of Python, and in case of a "Python 4" they can be > switched at once. > "python-*" is v2, by the way. This change adds "system-python" which is v3. I think this kind of implies something that isn't clearly stated in the Change itself. Namely, that the system-python version is independent of any other python version installed on the machine. One of the benefits(?) of that independence is that system-python can upgrade to newer python versions as soon as the tools that use it are ready (or all can be ported at once). This doesn't impact the machine's regular python install at all. Or if it is more beneficial to keep system-python at an older version because the tools are not ready, that is also possible without holding anything else back. >From a modularity perspective, this is a "Good Thing". It allows us to provide system tools that can be used to manage modules, without having to worry about dependencies of the module breaking the tooling itself. E.g. A app needs python-3.5.4 but the system tools need python-3.2. In today's world, we're stuck until they can be synced. With system-python, a user could install the python-3.5.4 module for the machine use, and the system-tools still function without issue. (Forgive me if my contrived version numbers don't make sense. I'm not a python developer and it's an example. Don't get bogged down in technical details.) Yes, this is somewhat a form of bundling, with the implied security aspects. That is a main issue that needs solving in-general for modularity and frankly, we need to figure it out. josh -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/devel@xxxxxxxxxxxxxxxxxxxxxxx