Is this package ever going to stop being a huge blocker on everything?
(In reply to Michał Górny from comment #0) > Is this package ever going to stop being a huge blocker on everything? I'm afraid not, upstream pins the dependencies of packages that are known to regularly break backwards compatibility.
(In reply to Andrew Ammerlaan from comment #1) > (In reply to Michał Górny from comment #0) > > Is this package ever going to stop being a huge blocker on everything? > > I'm afraid not, upstream pins the dependencies of packages that are known to > regularly break backwards compatibility. Then the packager maintainer needs to regularly test and unpin the deps.
(In reply to Michał Górny from comment #0) > Is this package ever going to stop being a huge blocker on everything? This is also why I was against stabilizing spyder at all, and was hoping we could keep it in ~. Spyder is very annoying to test, because different modules have varying test deps vs. runtime deps when it comes to forced versions, and that confuses portage everytime I'm testing spyder. Now for a solution I do wonder if it's in any capability possible, or appropriate to package our own spyder-bin with all these deps bundled in. I see upstream provides -bin packages for Windows and MacOS but not for linux. That'd allow cleaning probably 100 packages from ::gentoo too. Then again the maintenance and interaction with upstream should get easier with Andrew possibly getting commit access soon.
(In reply to Michał Górny from comment #2) > (In reply to Andrew Ammerlaan from comment #1) > > (In reply to Michał Górny from comment #0) > > > Is this package ever going to stop being a huge blocker on everything? > > > > I'm afraid not, upstream pins the dependencies of packages that are known to > > regularly break backwards compatibility. > > Then the packager maintainer needs to regularly test and unpin the deps. The problem is that the test suite takes 2 hours to run, if it works at all. I'm doing my best to keep the dependencies as unrestricted as possible, but often I find that things break whenever I use a newer version than explicitly specified. If there is a patch to fix that, I of course add it, but I sadly cannot fix everything. The nature of spyder as an IDE with tons of features, is that it has a gazillion dependencies as a consequence, and it is almost unavoidable that there is not some incompatibility somewhere. > Now for a solution I do wonder if it's in any capability possible, or appropriate to package our own spyder-bin with all these deps bundled in. I see upstream provides -bin packages for Windows and MacOS but not for linux. That'd allow cleaning probably 100 packages from ::gentoo too. The disadvantage of cleaning all those packages is that there actually is a valid use case for using most of those packages outside of spyder. (e.g. even spyder-kernels can and often is used without spyder itself, same for python-language-server) > This is also why I was against stabilizing spyder at all, and was hoping we could keep it in ~. Sigh, fine, I'll close the stabilization request. It seems that everyone but me is very opposed to stabilizing this.
(In reply to Andrew Ammerlaan from comment #4) > > Sigh, fine, I'll close the stabilization request. It seems that everyone but > me is very opposed to stabilizing this. I genuinely hope you understand it's not about rudeness, but work cost vs. benefit at the moment. Hopefully you can soon help in that area more, performing stabilizations etc.
(In reply to Joonas Niilola from comment #5) > (In reply to Andrew Ammerlaan from comment #4) > > > > Sigh, fine, I'll close the stabilization request. It seems that everyone but > > me is very opposed to stabilizing this. > > I genuinely hope you understand it's not about rudeness, but work cost vs. > benefit at the moment. Hopefully you can soon help in that area more, > performing stabilizations etc. I do, I understand why you'd be hesitant to stabilize this considering the large amount of dependencies. My stable request is of course just that, a request, I am not the one who would have to do the actual work and I wouldn't want to force or put pressure on anyone to do anything. And if everyone feels like it would not be worth the effort than that is fine, no hard feelings. (I disagree, but then again I am heavily biased because I care a lot about this package :P )
I don't see stable request as being any problem. The deps are PITA whether it's stable or not.
(In reply to Michał Górny from comment #7) > I don't see stable request as being any problem. The deps are PITA whether > it's stable or not. IMHO the problem is those deps breaking backwards compatibility *a lot*, not that the spyder ebuild has <foo/bar deps, that is just a logical consequence of the former. E.g. the pyls/spyder ebuilds have a restricted dependency on jedi, and that is not because upstream is being too careful, that is because even a minor version bump of jedi is known to completely break things. Same story for parso.
With the only versions pycodestyle-2.7.0 and spyder-5.0.4 (for spyder-5) left, I have to mask spyder-5.
(In reply to Bernd from comment #9) > With the only versions pycodestyle-2.7.0 and spyder-5.0.4 (for spyder-5) > left, I have to mask spyder-5. This is the package.mask that I have to prevent portage from complaining too much about spyder: >=dev-python/pycodestyle-2.7.0 >=dev-python/pyflakes-2.3.0 >=dev-python/autopep8-1.5.6 >=dev-python/flake8-3.9.0 The root of this problem is that, for some unkown reason, spyder is still using python-language-server (which hasn't been updated for more than half a year), instead of the fork (python-lsp-server) that was made by the spyder community and has been updated more recently and would allow relaxing some of these restrictions. I'll go bother upstream about this when I have time.
Sorry got my last comment wrong, it's not pycodestyle which causes an issue, but autopep8 has only 1.5.7 left. autopep8-1.5.7 depends on >=pycodestyle-2.7.0, which needs to be masked for spyder-5.0.4. !!! All ebuilds that could satisfy ">=dev-python/pycodestyle-2.7.0[python_targets_pypy3(-)?,python_targets_python3_8(-)?,python_targets_python3_9(-)?,-python_single_target_pypy3(-),-python_single_target_python3_8(-),-python_single_target_python3_9(-)]" have been masked. !!! One of the following masked packages is required to complete your request: - dev-python/pycodestyle-2.7.0::gentoo (masked by: package.mask) - dev-python/pycodestyle-2.7.0::gentoo-git (masked by: package.mask) (dependency required by "dev-python/autopep8-1.5.7::gentoo" [ebuild]) (dependency required by "dev-python/spyder-5.0.4::gentoo" [ebuild]) (dependency required by "@dev-tools" [set]) (dependency required by "@selected" [set]) (dependency required by "@world" [argument])
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=5bb6a621811604d741a34f93b8e95ec960c2e167 commit 5bb6a621811604d741a34f93b8e95ec960c2e167 Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2021-06-12 10:23:39 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2021-06-12 10:25:20 +0000 dev-python/spyder: switch pyls --> python-lsp-server We are running into a dependency mess with pyls because it hasn't been updated for over 6 months. We can no longer wait for upstream to make the switch to their own fork of the project (though I still expect this soonish) Bug: https://bugs.gentoo.org/783618 Bug: https://bugs.gentoo.org/783615 Package-Manager: Portage-3.0.19, Repoman-3.0.3 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> ...{spyder-4.2.5.ebuild => spyder-4.2.5-r1.ebuild} | 35 +++++++++++++++------ ...{spyder-5.0.4.ebuild => spyder-5.0.4-r1.ebuild} | 36 ++++++++++++++++------ 2 files changed, 52 insertions(+), 19 deletions(-)
Upstream is waiting for pyls-black to make the switch, however we can no longer wait for this because things are getting too messy. I have added the python-lsp-black fork of pyls-black and added a find+sed to the spyder ebuild to switch out python-language-server for the updated fork python-lsp-server. There shouldn't be any issues (and there weren't when I tested it just now). However, if you already have a configuration file for spyder in your home directory then spyder may still attempt to start pyls instead of pylsp, which will of course fail. To workaround this either reset your spyder configuration or manually go to "Tools --> Preferences --> Completion and linting --> Advanced", click the "Enable advanced settings" checkbox and change "Module for the Python language server" from "pyls" to "pylsp". I'll change the title of this bug so users who run into this can find this workaround.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=050b52ffac32fedb3f3c355340c64b868e8a7e9d commit 050b52ffac32fedb3f3c355340c64b868e8a7e9d Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2021-06-14 11:16:04 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2021-06-14 11:25:01 +0000 profiles/package.mask: mask python-language-server for removal unmaintained upstream, alternatives available. Bug: https://bugs.gentoo.org/783615 Bug: https://bugs.gentoo.org/795924 Bug: https://bugs.gentoo.org/783618 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> profiles/package.mask | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+)
