"Code Analysis" pane and "Run code analysis" menu are missing in spyder-5.1.5-r1 installed from portage. The F8 key does not work too. Reproducible: Always Steps to Reproduce: 1. Open any python file in spyder 2. Press F8 3. Actual Results: Nothing happens. Expected Results: Open "Code Analysis" pane with pylint results. The cause of the problem is that ebuild deletes all lines with the "pylint" word from the setup.py file. Not only from "install_requires", but also from "spyder_plugins_entry_points" list. After applying the following patch, the Code Analysis plugin becomes available. --- spyder-5.1.5-r1.ebuild 2021-10-04 23:41:16.162815202 +0300 +++ spyder-5.1.5-r101.ebuild 2021-11-03 05:33:17.395823424 +0300 @@ -135,7 +135,7 @@ python_prepare_all() { -e '/python-lsp-server/d' \ -e '/parso/d' \ -e '/jedi/d' \ - -e '/pylint/d' \ + -e '/pylint.*>/d' \ {setup.py,requirements/conda.txt} || die sed -i \ -e "/^PYLS_REQVER/c\PYLS_REQVER = '>=0.0.1'" \
Maybe a good reason to avoid spooky seds in future?
(In reply to Sam James from comment #1) > Maybe a good reason to avoid spooky seds in future? Yes the sed's are not nice here but upstream is doing some annoying things with their deps that need fixing. Pylint is actually the perfect example, spyder does not directly use pylint. Instead spyder requires pyls-spyder which requires python-lsp-server which requires pylint, despite this spyder upstream insists on depending on pylint directly (for bundling reasons on other platforms I assume). Now this becomes annoying when for example python-lsp-server has an incompatibility with pylint>=2.10, and thus spyder and python-lsp-server record a dependency on <pylint-2.10.0. At some point python-lsp-server will gain a fix for this incompatibility and thus this restriction is lifted in the python-lsp-server ebuild upon version bump. However, if we were to follow upstreams deps in the spyder ebuild, users of spyder would still be stuck on pylint<2.10.0, for absolutely no reason because a pylint>=2.10.0 compatible version of python-lsp-server is in fact installed. So what? You ask. Why not just omit the dependencies from the ebuild but leave the spyder source code as is? Well because spyder actually checks if the dependencies are installed as specified every time you start it, and pops up an annoying message if you do not have the correct versions installed. So we have to trick it by changing the specified dependencies in the source code as well. The sed's in the ebuild are my attempt at fixing this mess and ending the stream of "Spyder prevents cleanup of package version X" bugs. Of course we could do patches instead, but this would have to be redone on every version bump. And I would rather not maintain a whole set of patches that upstream is not going to accept anyway. Anyway, I'll make the sed's a bit more specific so they won't accidentally hit other things. Sorry for the inconvenience @Petr, the Code Analysis widget will return soon!
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=d2b7cdd9d107ba6b170d933fd89d7823e284b6bd commit d2b7cdd9d107ba6b170d933fd89d7823e284b6bd Author: Andrew Ammerlaan <andrewammerlaan@gentoo.org> AuthorDate: 2021-11-06 16:20:02 +0000 Commit: Andrew Ammerlaan <andrewammerlaan@gentoo.org> CommitDate: 2021-11-06 16:20:19 +0000 dev-python/spyder: bring back Code Analysis It was accidentally hit by our sed's Closes: https://bugs.gentoo.org/821409 Package-Manager: Portage-3.0.28, Repoman-3.0.3 Signed-off-by: Andrew Ammerlaan <andrewammerlaan@gentoo.org> .../{spyder-4.2.5-r2.ebuild => spyder-4.2.5-r3.ebuild} | 12 ++++++++++-- .../{spyder-5.0.5-r1.ebuild => spyder-5.0.5-r2.ebuild} | 12 ++++++++++-- .../{spyder-5.1.5-r1.ebuild => spyder-5.1.5-r2.ebuild} | 10 +++++++++- 3 files changed, 29 insertions(+), 5 deletions(-)
(In reply to Andrew Ammerlaan from comment #2) > (In reply to Sam James from comment #1) > > Maybe a good reason to avoid spooky seds in future? > > Yes the sed's are not nice here but upstream is doing some annoying things > with their deps that need fixing. Pylint is actually the perfect example, > spyder does not directly use pylint. Instead spyder requires pyls-spyder > which requires python-lsp-server which requires pylint, despite this spyder > upstream insists on depending on pylint directly (for bundling reasons on > other platforms I assume). Just to be clear, I promise I wasn't having a go at you -- it's just a good example of where seds can be problematic. I recently had to fix another ebuild (unrelated to this) where some features have been silently broken in the past :( I wonder if a script to quickly apply a sed and generate a patch would be useful, so that we can eyeball the changes and make sure nothing broke compared to the last release. Thanks for your extensive reply btw!
(In reply to Sam James from comment #4) > Just to be clear, I promise I wasn't having a go at you -- it's just a good > example of where seds can be problematic. > > I recently had to fix another ebuild (unrelated to this) where some features > have been silently broken in the past :( No worries, any annoyance that might emanate from my reply is directed at upstream and not at you, I'm sorry if my reply came off as a bit defensive. > I wonder if a script to quickly apply a sed and generate a patch would be > useful, so that we can eyeball the changes and make sure nothing broke > compared to the last release. I like this idea. A quick and easy way to implement something like this would be to have something run `git init && git add . && git commit -m 'init'` before running src_prepare and `git diff` after. Maybe we could toggle such behaviour with an environment variable or FEATURE: SRC_PREPARE_TRACK or maybe SRC_PREPARE_VERBOSE. Though such a diff might become rather large, and any breakage might still be lost within everything else.
