On Wed, Jul 4, 2018 at 5:12 PM Nathan Cutler <ncutler@xxxxxxx> wrote: > > Hi Kefu, Patrick, Rishabh, Python 3 enthusiasts, and future Python 3 > users (i.e. everybody on this list, presumably): > > > so we already enable WITH_PYTHON3 for deb/rpm packaging, and for "make > > check" runs. > > Taken literally, this is true. But running cmake with WITH_PYTHON3=ON is > not sufficient to cause Ceph to actually use Python 3. (CAVEAT: I am > only familiar with the RPM spec file builds, so this commentary is > limited to those, and the usual "correct me if I'm wrong about any of > this" caveat applies as well!) > > With that out of the way, I'll start my exposition which - I'm sorry to > say - has no "tl;dr" because I honestly do not know how to explain this > via a one-liner. > > Unless special measures [1] are taken at build time, the spec file runs > cmake with -DWITH_PYTHON2=ON -DWITH_PYTHON3=ON. At first glance, this > seems reasonable and correct: we do want our builds to support both > Python 2 and Python 3, right? Turns out there are design considerations > that currently make this "both-ness" impossible to achieve. > > At the spec file level, the problem is there are packages, like > ceph-common, which "Require" the Ceph python bindings. And it is not > possible to do "Require: python2-rados" and "Require: python3-rados" at > the same time: you have to choose one or the other. > > (It's probably useful to note here that, as far as RPM is concerned in > currently supported distros, "python-rados" is just a synonym for > "python2-rados".) > > Even at the cmake level, it's not possible to do both because the MGR > has an embedded Python subinterpreter which cannot be both Python 2 and > Python 3 at the same time. > > So, what to do? How could we obtain a "real" Python 3 build that could > be tested using teuthology? For that, the RPMs would need to be built > with [1]. But the world at large is not ready for Ceph to be built this > way (not even for Nautilus AFAICT)! > > My proposed solution for this is to implement a "python3" build flavor > in the CI infrastructure - similar to the existing "notcmalloc" build > flavor. Then, it would be possible to include "flavor: python3" in test > yaml for consumption by teuthology. I have not yet written any code in > this direction, though, so for the time being this "solution" has a > hollow ring to it. I'm a bit fuzzy on which distro does what, but I had thought we might do pure python3 builds for the distros that have already made the leap (e.g. Ubuntu bionic). That's kind of a hacky way to get some mixed python2 vs. python3 testing (assuming we use a mixture of ubuntu and centos in testing). Am I being naive to think that we mainly just need to build the python version that ships with a given distro? Are there people who would want e.g. python 3 packages for CentOS 7? John > > HTH, > Nathan > > [1] -DWITH_PYTHON2=OFF -DMGR_PYTHON_VERSION=3 > -- > To unsubscribe from this list: send the line "unsubscribe ceph-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- To unsubscribe from this list: send the line "unsubscribe ceph-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
