On 29. 04. 20 21:42, Lloyd Kvam wrote:
What you say is true. I still don't agree that "python3.9" as a package name annoys humans.
I am not a package pro, but simply reading along as an interested human user. To me, adding periods in package names can be confusing.
My sentence was about "python3.9" not being more annoying than "python-3.9".
I wonder, why do you consider periods in names confusing?
We have around ~100 source package names with dot. Most of them have versions, e.g.:
clang9.0 dotnet3.1 freerdp1.2 llvm5.0 llvm6.0 llvm9.0 jboss-jsf-2.1-api jboss-jsf-2.2-api jboss-jsp-2.2-api jboss-jsp-2.3-api
Some use dot as a separator, e.g.:
R-R.utils R-data.table R-futile.logger R-futile.options R-gamlss.dist R-lambda.r R-statnet.common openoffice.org-diafilter python-boolean.py
I will adjust to whatever you decide to do, and I am not informed enough to want a vote in how this decision comes down, but I do not see an advantage to this sort of change.
The biggest advantage I see is getting closer to upstream.
The command that the user executes is "python3.9", not "python39".
I know no other place in the Python ecosystem where Python 3.9 is called "python39" than the names of RPM packages (or other Linux distro packages).
I've googled "python36", "python37" etc. and all I could find was Fedora/RHEL/CentOS related (or AUR). We have invented that naming ourselves and we don't like being different :)
(There is the "py39" short identifier used e.g. in tox, but not "python39".)
On Wed, 29 Apr 2020 at 18:44, Miro Hrončok mhroncok@redhat.com wrote:
On 29. 04. 20 21:42, Lloyd Kvam wrote:
What you say is true. I still don't agree that "python3.9" as a package
name
annoys humans.
I am not a package pro, but simply reading along as an interested human
user. To me, adding
periods in package names can be confusing.
My sentence was about "python3.9" not being more annoying than "python-3.9".
I wonder, why do you consider periods in names confusing?
We have around ~100 source package names with dot. Most of them have versions, e.g.:
clang9.0
The standard confusing part is if you are used to seeing a . only in the version or release parts.. you scan down and see
dotnet3.1-3.1.2-40
my usual mistake is where I do a stupid programming and do something like
ls -1 | awk '{split($0,a,"."); print a[1]}' | whatever I needed for just the names of rpms
which for most packages will give me the Name-Ver[.sion removed]. it is lazy script programming but it works often enough that my brain wants it to work all the time than doing something like
ls -1 *rpm | xargs rpm --qf='%{NAME}\n' -qp | whatever i needed for just the names of the rpms.
dotnet3.1 freerdp1.2 llvm5.0 llvm6.0 llvm9.0 jboss-jsf-2.1-api jboss-jsf-2.2-api jboss-jsp-2.2-api jboss-jsp-2.3-api
Some use dot as a separator, e.g.:
R-R.utils R-data.table R-futile.logger R-futile.options R-gamlss.dist R-lambda.r R-statnet.common openoffice.org-diafilter python-boolean.py
I will adjust to whatever you decide to do, and I am not informed enough
to want a vote in how
this decision comes down, but I do not see an advantage to this sort of
change.
The biggest advantage I see is getting closer to upstream.
The command that the user executes is "python3.9", not "python39".
I know no other place in the Python ecosystem where Python 3.9 is called "python39" than the names of RPM packages (or other Linux distro packages).
I've googled "python36", "python37" etc. and all I could find was Fedora/RHEL/CentOS related (or AUR). We have invented that naming ourselves and we don't like being different :)
(There is the "py39" short identifier used e.g. in tox, but not "python39".)
-- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
On Wed, Apr 29, 2020 at 7:04 PM Stephen John Smoogen smooge@gmail.com wrote:
On Wed, 29 Apr 2020 at 18:44, Miro Hrončok mhroncok@redhat.com wrote:
On 29. 04. 20 21:42, Lloyd Kvam wrote:
What you say is true. I still don't agree that "python3.9" as a package name annoys humans.
I am not a package pro, but simply reading along as an interested human user. To me, adding periods in package names can be confusing.
My sentence was about "python3.9" not being more annoying than "python-3.9".
I wonder, why do you consider periods in names confusing?
We have around ~100 source package names with dot. Most of them have versions, e.g.:
clang9.0
The standard confusing part is if you are used to seeing a . only in the version or release parts.. you scan down and see
dotnet3.1-3.1.2-40
my usual mistake is where I do a stupid programming and do something like
ls -1 | awk '{split($0,a,"."); print a[1]}' | whatever I needed for just the names of rpms
which for most packages will give me the Name-Ver[.sion removed]. it is lazy script programming but it works often enough that my brain wants it to work all the time than doing something like
ls -1 *rpm | xargs rpm --qf='%{NAME}\n' -qp | whatever i needed for just the names of the rpms.
Splitting on the second to last dash of an rpm file name will *always* give you the name on the left side, and the version-release on the right side, so I usually do a split that way. :)
-- 真実はいつも一つ！/ Always, there's only one truth!
On 30. 04. 20 1:07, Neal Gompa wrote:
my usual mistake is where I do a stupid programming and do something like
ls -1 | awk '{split($0,a,"."); print a[1]}' | whatever I needed for just the names of rpms
which for most packages will give me the Name-Ver[.sion removed]. it is lazy script programming but it works often enough that my brain wants it to work all the time than doing something like
ls -1 *rpm | xargs rpm --qf='%{NAME}\n' -qp | whatever i needed for just the names of the rpms.
Splitting on the second to last dash of an rpm file name will*always* give you the name on the left side, and the version-release on the right side, so I usually do a split that way.
I have this in my PATH (called pkgname):
#!/usr/bin/python3 import fileinput
for line in fileinput.input(): print('-'.join(line.split('-')[:-2]))
On Thu, 2020-04-30 at 01:10 +0200, Miro Hrončok wrote:
On 30. 04. 20 1:07, Neal Gompa wrote:
my usual mistake is where I do a stupid programming and do something like
ls -1 | awk '{split($0,a,"."); print a[1]}' | whatever I needed for just the names of rpms
which for most packages will give me the Name-Ver[.sion removed]. it is lazy script programming but it works often enough that my brain wants it to work all the time than doing something like
ls -1 *rpm | xargs rpm --qf='%{NAME}\n' -qp | whatever i needed for just the names of the rpms.
Splitting on the second to last dash of an rpm file name will*always* give you the name on the left side, and the version-release on the right side, so I usually do a split that way.
I have this in my PATH (called pkgname):
#!/usr/bin/python3 import fileinput
for line in fileinput.input(): print('-'.join(line.split('-')[:-2]))
how about:
print(line.rsplit("-", 2)[0])
?
On 30. 04. 20 1:21, Adam Williamson wrote:
I have this in my PATH (called pkgname):
#!/usr/bin/python3 import fileinput
for line in fileinput.input(): print('-'.join(line.split('-')[:-2]))
how about:
print(line.rsplit("-", 2)[0])
That's indeed probably nicer.
On 30. 04. 20 8:50, Miro Hrončok wrote:
On 30. 04. 20 1:21, Adam Williamson wrote:
I have this in my PATH (called pkgname):
#!/usr/bin/python3 import fileinput
for line in fileinput.input(): print('-'.join(line.split('-')[:-2]))
how about:
print(line.rsplit("-", 2)[0])
That's indeed probably nicer.
And a bit faster.
New:
$ wc -l tmplst; time cat tmplst | pkgname > /dev/null 11372184 tmplst
real 0m8,924s user 0m8,759s sys 0m0,489s
Old:
$ wc -l tmplst; time cat tmplst | pkgname > /dev/null 11372184 tmplst
real 0m10,425s user 0m10,200s sys 0m0,584s
Le jeudi 30 avril 2020 à 00:38 +0200, Miro Hrončok a écrit :
My sentence was about "python3.9" not being more annoying than "python-3.9".
I wonder, why do you consider periods in names confusing?
…
jboss-jsf-2.1-api
Another example where the hyphen helps reading. The version is mid package name (that can easily happen when the SRPM is versionned but subpackages not), and the hyphens nicely separe a version qualifier from the rest of the name.
That means, a parser (human or not) can match -numeric- and not be confused by 0ad, go2rpm, 0install, cookies4all, etc where there are some numeric elements in the middle of the upstream name, but they are not versions as such.
Old human languages did not use word separators like space in writing, because "everyone knew" where one word started and the next finished. Even scholars that spent their life studying one of those past civilization find them endlessly confusing by today’s standards.
And yes, I am quite sensitive to the regularity of version syntax by now, after years of trying to align the git non-idea of a version¹, the various forges "straightening up" of git non-ideas, the go interpretation of all of the above, and the rpm idea of a version, in Fedora macros. And don’t get me started on pseudoversions (all the above kinds) here.
Clever “it’s obvious in the few cases we imagine today, we do not need a clean version separator” syntaxes fail hard once exposed to the real world.
Regards,
¹ Linus did not bother with a clean version reference in git. People build sand castles on one man page example where Linus workarounds his own tooling defficiency by using vx.y as tag in an example.
That means in git, the vxx.y tag is probably a version, vampire is probably not, vnumericsomething may be a version with some made up pre/post release garbage at the end, or something else entirely.
All because Linus did not bother defining a clean version separator but reused the v letter, because “it was obvious” in the limited use cases he imagined.
Le jeudi 30 avril 2020 à 10:03 +0200, Nicolas Mailhot a écrit :
Clever “it’s obvious in the few cases we imagine today, we do not need a clean version separator” syntaxes fail hard once exposed to the real world.
Also, to get back to the original subject, the whole python package renaming, is due to someone thinking he could dispense with the dots in python versions in the past, because the result was “obvious” to everyone. And, years later, it is not so obvious and people think it confusing.
Dispensing with the hyphen to separate from the rest of the package name because it is “obvious”, is the exact same false clever economy.
Regards,
Le jeudi 30 avril 2020 à 10:03 +0200, Nicolas Mailhot a écrit :
Old human languages did not use word separators like space in writing, because "everyone knew" where one word started and the next finished. Even scholars that spent their life studying one of those past civilizations find them endlessly confusing by today’s standards.
Of course past civilizations had other constrains. It is expensive to carve a separator on your stone tablet. Physical space on the obelisk you carried up from another region entirely is at a premium. But, fun fact, the Egyptians did make an exception for the ruler names (can’t get subjects to confuse where the ruler name starts and ends), and this exception is the sole reason we can read ancient Egyptian today (Champollion’s breakthrough started with the nicely separated Pharao names).
On Wednesday, April 29, 2020 3:38:36 PM MST Miro Hrončok wrote:
The command that the user executes is "python3.9", not "python39".
Let's be realistic. The command they run is 'python', 'python2' or 'python3'. Sure, it's a symlink, but that's what users actually type to be executed.
On Sat, May 9, 2020 at 4:57 PM John M. Harris Jr johnmh@splentity.com wrote:
On Wednesday, April 29, 2020 3:38:36 PM MST Miro Hrončok wrote:
The command that the user executes is "python3.9", not "python39".
Let's be realistic. The command they run is 'python', 'python2' or 'python3'. Sure, it's a symlink, but that's what users actually type to be executed.
If you're working in a multi-Python environment (as in multiple versions of Python 3), then you use the fully qualified interpreter name (e.g. python3.9 for Python 3.9). I do this for development to ensure things work on Python 3.5, 3.6, and 3.8 regularly.
On 09. 05. 20 22:56, John M. Harris Jr wrote:
On Wednesday, April 29, 2020 3:38:36 PM MST Miro Hrončok wrote:
The command that the user executes is "python3.9", not "python39".
Let's be realistic. The command they run is 'python', 'python2' or 'python3'. Sure, it's a symlink, but that's what users actually type to be executed.
The entire point of packaging Python 3.5, 3.6, 3.7, 3.8 and 3.9 is to support users who need to be that explicit. The fact that you don't consider this use case dos not justify the "let's be realistic" comment. Please, don't.
On Saturday, May 9, 2020 2:40:02 PM MST Miro Hrončok wrote:
On 09. 05. 20 22:56, John M. Harris Jr wrote:
On Wednesday, April 29, 2020 3:38:36 PM MST Miro Hrončok wrote:
The command that the user executes is "python3.9", not "python39".
Let's be realistic. The command they run is 'python', 'python2' or 'python3'. Sure, it's a symlink, but that's what users actually type to be executed.
The entire point of packaging Python 3.5, 3.6, 3.7, 3.8 and 3.9 is to support users who need to be that explicit. The fact that you don't consider this use case dos not justify the "let's be realistic" comment. Please, don't.
In every environment I've seen a specific version used, the primary symlink is updated to point to the version that's supported or being used. For example, at work engineers asked for Python 2.7 to be installed on all of the systems in a given department, so my team installed the SCL, created a wrapper and updated the symlink 'python' to point to it.
On Sat, May 9, 2020 at 6:09 PM John M. Harris Jr johnmh@splentity.com wrote:
On Saturday, May 9, 2020 2:40:02 PM MST Miro Hrončok wrote:
On 09. 05. 20 22:56, John M. Harris Jr wrote:
On Wednesday, April 29, 2020 3:38:36 PM MST Miro Hrončok wrote:
The command that the user executes is "python3.9", not "python39".
Let's be realistic. The command they run is 'python', 'python2' or 'python3'. Sure, it's a symlink, but that's what users actually type to be executed.
The entire point of packaging Python 3.5, 3.6, 3.7, 3.8 and 3.9 is to support users who need to be that explicit. The fact that you don't consider this use case dos not justify the "let's be realistic" comment. Please, don't.
In every environment I've seen a specific version used, the primary symlink is updated to point to the version that's supported or being used. For example, at work engineers asked for Python 2.7 to be installed on all of the systems in a given department, so my team installed the SCL, created a wrapper and updated the symlink 'python' to point to it.
In *my* case, I'm producing RPMs and DEBs that are pointed specifically at each interpreter version. And I do both development using virtualenvs with different Python versions (and using tools like tox to do testing across the versions) and straight up system-style development targeting these interpreters when needed.
In fact, I *asked* for this change to be made because it makes *my* life simpler, and rationalizes things across Fedora and Debian/Ubuntu (which I frequently port back and forth). The fact that the team was considering it for other reasons was merely a lucky coincidence.
On 10. 05. 20 0:09, John M. Harris Jr wrote:
On Saturday, May 9, 2020 2:40:02 PM MST Miro Hrončok wrote:
On 09. 05. 20 22:56, John M. Harris Jr wrote:
On Wednesday, April 29, 2020 3:38:36 PM MST Miro Hrončok wrote:
The command that the user executes is "python3.9", not "python39".
Let's be realistic. The command they run is 'python', 'python2' or 'python3'. Sure, it's a symlink, but that's what users actually type to be executed.
The entire point of packaging Python 3.5, 3.6, 3.7, 3.8 and 3.9 is to support users who need to be that explicit. The fact that you don't consider this use case dos not justify the "let's be realistic" comment. Please, don't.
In every environment I've seen a specific version used, the primary symlink is updated to point to the version that's supported or being used. For example, at work engineers asked for Python 2.7 to be installed on all of the systems in a given department, so my team installed the SCL, created a wrapper and updated the symlink 'python' to point to it.
Good for you. How does that support your argument?
On Saturday, May 9, 2020 11:58:43 PM MST Miro Hrončok wrote:
On 10. 05. 20 0:09, John M. Harris Jr wrote:
On Saturday, May 9, 2020 2:40:02 PM MST Miro Hrončok wrote:
On 09. 05. 20 22:56, John M. Harris Jr wrote:
On Wednesday, April 29, 2020 3:38:36 PM MST Miro Hrončok wrote:
The command that the user executes is "python3.9", not "python39".
Let's be realistic. The command they run is 'python', 'python2' or 'python3'. Sure, it's a symlink, but that's what users actually type to be executed.
The entire point of packaging Python 3.5, 3.6, 3.7, 3.8 and 3.9 is to support users who need to be that explicit. The fact that you don't consider this use case dos not justify the "let's be realistic" comment. Please, don't.
In every environment I've seen a specific version used, the primary symlink is updated to point to the version that's supported or being used. For example, at work engineers asked for Python 2.7 to be installed on all of the systems in a given department, so my team installed the SCL, created a wrapper and updated the symlink 'python' to point to it.
Good for you. How does that support your argument?
The first sentence was the supporting statement, the rest was providing an anecdote as supporting context.
-
Adam Williamson -
John M. Harris Jr -
Miro Hrončok -
Neal Gompa -
Nicolas Mailhot -
Stephen John Smoogen