On 4 December 2014 at 23:10, Bohuslav Kabrda <bkab...@redhat.com> wrote: > ----- Original Message ----- >> On Thu, Dec 04, 2014 at 12:51:40AM +1000, Nick Coghlan wrote: >> > >> > On 4 Dec 2014 00:38, "Bohuslav Kabrda" <bkab...@redhat.com> wrote: >> > > - (This is not really related to the switch, but more of a general >> > > remark) In >> > [4], it says that "python 3 version of the executable gains a python3- >> > prefix". >> > This is IMO bad, since upstream projects tend to name the versioned >> > binaries >> > "foo-3.4, foo-3" or "foo3.4, foo3". We should accept one of these - I'm not >> > really certain which one of them. I tried to discuss this several times on >> > distutils-sig mailing list, but without reaching a consensus. Either way, >> > prefixing with python3- doesn't make sense to me, because it's not similar >> > to >> > any upstream way and you don't find the binaries under their names using >> > tab >> > completion (e.g. foo<tab> doesn't tell you about python3-foo). >> > >> > Agreed. >> > >> > CPython & pip use the "foo3.4, foo3" convention, so that seems enough of a >> > reason to use that convention by default. We may want a "unless upstream >> > does >> > it differently" caveat though. >> > >> Second caveat here is that currently we use version suffixes to denote >> a command coming from a compat package. If we make this change we need to >> address that as well. So, you might have sphinx-build, sphinx-build-2, >> sphinx-build-2.7, sphinx-build-3, and sphinx-build-3.4 for the python >> interpreter. If you need a forwards or backwards compat package you might >> also have an 0.9 and 1.1 that you need to tack on. Possible solution here: >> use a "v" prefix for the compat package's version. So if the default >> package is 1.1, you would have the python-sphinx0.9 and python3-sphinx0.9 >> packages provide: >> >> * sphinx-build-v0.9 >> * sphinx-build-2-v0.9 >> * sphinx-build-2.7-v0.9 >> * sphinx-build-3-v0.9 >> * sphinx-build-3.7-v0.9 > > I'd rather see sphinx-build-v0.9-3.4. IMO keeping the Python version at the > very end in every case is better. In other words, the binary would normally > be "sphinx-build-0.9" and we just append "-3.4" to it. > Also, this makes me realize more arguments to append Python version with > dash, not without it: > 1) sphinx-build-v0.93.4 would be very confusing (I do understand that this is > a downstream problem, but see the following point) > 2) Similarly, if there is an upstream whose entry_point/script ends with a > number (pep8 for example), it'd be highly confusing to use the notation > without dash, it would yield pep83.4 assuming the upstream community would > accept this scheme. This feels just wrong.
I think these are good reasons to default to using the dash if its Fedora adding it. The guideline could be something like "For Python executables, also provide symlinks with a '-X' and '-X.Y' suffix, unless upstream already provides appropriately versioned executables without the dash. For compatibility packages, the Python version is appended *after* the specific package version". Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ python-devel mailing list python-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/python-devel
