Community Packages

Please read this before reporting a bug:

Do NOT report bugs when a package is just outdated, or it is in Unsupported. Use the 'flag out of date' link on the package page, or the Mailing List.

REPEAT: Do NOT report bugs for outdated packages!

FS#51437 - [spyder] [spyder3] Rename spyder and spyder3 package to spyder2 and spyder

Attached to Project: Community Packages
Opened by Daniel (dbacc) - Tuesday, 18 October 2016, 22:45 GMT
Last edited by Muflone (muflone) - Saturday, 12 August 2017, 20:02 GMT
Task Type Feature Request
Category Packages
Status Closed
Assigned To Muflone (muflone)
Architecture All
Severity Low
Priority Normal
Reported Version
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 1
Private No



python defaults to python3. Similarly, spyder should default to spyder3.


Rename spyder and spyder3 package to spyder2 and spyder, resp.
This task depends upon

Closed by  Muflone (muflone)
Saturday, 12 August 2017, 20:02 GMT
Reason for closing:  Fixed
Additional comments about closing:  fixed in 3.2.0-1
Comment by Muflone (muflone) - Thursday, 20 October 2016, 21:36 GMT
Can you elaborate the reasons to do this?
Comment by Daniel (dbacc) - Friday, 21 October 2016, 02:38 GMT
It's mainly inconsistency.

I wanted to use spyder for python(3) and wasn't aware of the fact that there are actually 2 versions of it. So I searched for config/environment etc. settings to make spyder use python3 (of which there are none).
If it had had the correct and intuitive naming scheme this would have been much easier to figure out (since I would have looked for appropriate version in the first place).
Comment by Muflone (muflone) - Sunday, 23 October 2016, 11:39 GMT
I'm not convinced about this issues.
The package spyder provides spyder for Python 2.x, while the package spyder3 provides spyder for Python 3.x.

Your arguments about your difficulties in finding spyder for the Python 3.x are weak, you should have simply used pacman -Ss to search in the pacman database, like for any other package. If you think the package spyder3 has some issue in its description file a new bug.

There're instead three strong arguments about keeping this naming schemas:
1- Historically reasons: the original spyder package offered spyder for Python 2.x. When spyder was packaged for build for Python 3.x it got a new package name
2- Common naming: other distributions use the same naming, see debian [1] and fedora [2] for example
3- Users base: all the spyder users in both Arch Linux or others distributions use the spyder command to launch spyder for Python 2.x, changing this name would confuse all the spyder users

Comment by Muflone (muflone) - Sunday, 23 October 2016, 11:41 GMT
Whenever Arch Linux will get a general alternative manager (like debian update-alternative or archlinux-java) I will agree to rename spyder to spyder2 and let the users choose their alternative for the spyder symlink.
Comment by Daniel (dbacc) - Sunday, 23 October 2016, 14:46 GMT
  • Field changed: Percent Complete (100% → 0%)
2- These are pretty bad examples since their python installation defaults to python2. So their naming scheme is consistent.
1.- all python packages have historically been build for python2. However, arch renamed all python2 packages to python2-* and python3 packages to python-*.
This renaming causes confusion (-3), however it causes even more confusion if half of the packages use the old naming scheme and the other half uses the new scheme.
This behavior is unexpected! That's why I got confused and probably many others will, too.
Comment by Muflone (muflone) - Sunday, 23 October 2016, 14:57 GMT
Please open a discussion on the arch-general mailing list.
I don't think the spyder package and executable should be renamed to spyder2, it will be inconsistent with any other distributions and it will confuse the current spyder users.
The benefit in renaming the executable would be nearly to zero.

Arch has renamed the python packages, not the app packages nor the app commands.
Comment by Doug Newgard (Scimmia) - Sunday, 23 October 2016, 15:32 GMT
No, but applications generally aren't packaged for both. They're packed for the latest version of python they support. I can understand needing both here, but the legacy one should generally not be default.
Comment by Eli Schwartz (eschwartz) - Thursday, 03 August 2017, 05:51 GMT

AFAIK Arch has, in fact, renamed the app commands for the python2 version of any python package that is available in our repos as both a Python 3 and Python 2 version. This is because pretty much any set of packages that provides both a python3 and python2 executable for the same software, is providing software meant to work *with* the python3 or python2 interpreter itself, or manipulate python3 or python2 source code files.

sphinx stuff
sundry scripts installed by python2-pillow

And that's just whatever happens to be installed on my machine at the moment (`ls /usr/bin/*2`)

I really don't see why a python IDE should have package names and executable paths that strongly confuse Arch users who have been led to expect this naming scheme... due to Arch Linux pushing python3 as the default python and essentially forcing the Python community to implement PEP 394.
I'd also note that PEP 394 *mandates* using the ${app}2 and ${app}3 executable names for all ${app}'s that come in the python2 and python3 distributions, with ${app} as a symlink to whichever python version is the default system python. (They recommend python2 as the default python, but leave it to as a distribution choice.)

This is pretty basic PEP 394 compliance at stake here. I think, considering Arch's role in forcing the PEP on the entire Python community, that it behooves us to respect it ourselves...
Comment by Muflone (muflone) - Saturday, 05 August 2017, 18:28 GMT

I hope you won't get me wrong, so please read the following comment with the maximum patience and wish to discuss this argument, as I am against this name change.

The whole PEP 394 refers only to the python commands, not to any third party application/module.

The spyder3 name was given upstream [1] [2], it's not due to the distributions choices.

In the upstream repository every reference to spyder is meant for the Python 2.x executable, while spyder3 is meant for the Python 3.x executable. Every Arch Linux user with some Spyder issue would open a ticket referring to the spyder command with a big confusion between upstream author and final user or reporter.
I don't think the Arch Linux force should never go against the upstream naming scheme.

In every distribution in the world any *3 command refers to the python 3.x version, and *2 refers to the python 2.x.
So I think the best solution would be to have spyder3 and spyder2 explicit names without any spyder symlink. (I'm against this change too but if many users think this would be better, I could change idea, while still going against the upstream decisions)

Comment by Muflone (muflone) - Saturday, 05 August 2017, 18:47 GMT Comment by Eli Schwartz (eschwartz) - Sunday, 06 August 2017, 15:14 GMT
Well, seems like they're okay with us making this change. ;)
Comment by Muflone (muflone) - Tuesday, 08 August 2017, 12:35 GMT
Okay, I'll update the package for the newer version in the next hours or tomorrow
Comment by Hao (qft) - Friday, 11 August 2017, 20:05 GMT
Basically all python packages in Arch Linux use python3 by default without extra qualification, and only use python2 if the package names are EXPLICITED qualified with *2.

I think it is more important to be consistent with other packages within the Arch Linux distribution, than to be consistent with other distributions. Arch Linux is already different from other distributions in many ways. It is not confusing as long as we are consistently different. People coming from other distributions will be more confused if the python executable, ipython, and idle all points to python3 by default, while spyder uses a different python version.
Comment by Eli Schwartz (eschwartz) - Friday, 11 August 2017, 22:18 GMT
Oh, while you are at it, the package_*() functions should not be doing the work of prepare() and build().

Traditionally, you would have a prepare() function that does cp -r "${pkgbase}-${pkgver}"{,-py2}, then patch each of those dirs, then run `python build` in the build() function.
Comment by Muflone (muflone) - Saturday, 12 August 2017, 20:02 GMT
fixed in 3.2.0-1