On Tue, Apr 17, 2018 at 4:27 PM, Nathan Cutler <ncutler@xxxxxxx> wrote: >>> + src/pybind/ceph_volume_client.py >>> >>> Other projects use ceph_volume_client [1] and so simply porting to >>> python3 is not trivial, right? As a Python casual: what's the >>> suggested thing to do here? >> >> >> I would suggest dual compatibility like what ceph-volume provides. In >> our case, it doesn't matter what you use, the code just works >> no need to change/remove anything. >> >> That would be at odds to what Nathan is suggesting though, which is a >> hard change to Python 3. > > > Hm, not sure what hard/soft means in this context. For any given script, > either it runs with Python 3, or it doesn't. And this is determined by the > shebang. (Unless the shebang is omitted, of course.) > > I was very surprised to find out that, in SLES and openSUSE, the symlink > /usr/bin/python -> /usr/bin/python2 will not be changed even when the > migration of the underlying distro to Python 3 is complete. > > But then my colleagues explained why that is, and I "saw the light". Since > every single script in the distro has to be audited for Python 3 > compatibility, anyway, it makes sense to have the shebang be an explicit > declaration of said compatibility. That is what I thought about a hard requirement: if we are being explicit with a shebang that points to python3, then we aren't allowing anything other than python 3. > > By retaining the symlink at it is, all scripts start out the migration > process with an explicit declaration that they are compatible with Python 2. > Compatibility with Python 3 is signalled not by saying "it's OK with Python > 3, we tried it". It's signalled by changing the shebang. > > And this isn't unique to SUSE. Fedora is treating the shebang in the same > way, apparently. [2] > > It may be true that a given script is fine with Python 3, but as long as the > shebang says "python" (i.e. python2), there's no way to really find out, is > there? (Barring things like Josh's suggestion of changing the shebang on the > fly via a teuthology task/workunit, which is fine if we decide we need a > transition period, which it looks like we will.) The way ceph-volume is ensuring Python 3 compatibility is by running tests on Python 3.X environments. We do find out when we accidentally introduce issues for Python3-only environments. But maybe you mean something else about "really finding out" ? I'm fine moving forward with whatever distros prefer, including an explicit python3 shebang, just saying that ceph-volume has been py3-ready since the beginning and this wouldn't be a problem. > > Nathan > > [1] > https://github.com/kubernetes-incubator/external-storage/blob/master/ceph/cephfs/cephfs_provisioner/cephfs_provisioner.py#L27 > [2] > https://fedoraproject.org/wiki/FinalizingFedoraSwitchtoPython3#.2Fusr.2Fbin.2Fpython > > -- > 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
