Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Future of Spyder #17155

Open
ma-sadeghi opened this issue Jan 7, 2022 · 38 comments
Open

Future of Spyder #17155

ma-sadeghi opened this issue Jan 7, 2022 · 38 comments
Assignees
@ccordoba12 @steff456
Labels
status:Awaiting Followup

Comments

@ma-sadeghi
Copy link

First, let me express my strongest gratitude towards the developers of Spyder. I've been using Spyder since I learned how to code in Python, which dates back to 2015, and I still use it for almost all of my Python projects. It's a great piece of software put together by awesome developers and I'm truly grateful for all your time/efforts that you've put into creating Spyder without expecting any monetary returns.

I'm sure you're all familiar with VSCode. Obviously, being backed by a giant company like Microsoft with virtually infinite resources definitely helps developing and maintainng such a big project, and I'm sure if you've used VSCode, you'll agree that it too is a great piece of software.

I was wondering if you guys have every considered joining forces and creating a fully-fledged extension for VSCode. If you know Julia, you probably know that developers of Juno (the used-to-be-goto-IDE for Julia) have taken a similar course of action and are now developing the julia-vscode extension. For Julia, it's worked pretty well and the users love the new extension. Juno is still maintained, but not being actively developed.

I opened up this issue just to toss around this idea see what you guys think. Many thanks once again!
@arita37
Copy link

arita37 commented Jan 8, 2022

To add my comments, on this topic:
--> Am still using Spyder 3 ...
Why ?
Very stable, It barely never crashes : very strong point (esp. in middle of big data analysis....)
Linter/Auto-completion works fine, without bugging (not perfect, but basics work fine).
Variable, DataFrame Pane visualizer work fine, without bugs.
Jupyter Notebook plugin work, without major issues.

What I found missing in Spyder 4, Spyder 5 :
Lack of stability at each release: each release solves 20% of bugs, but add 5-10% of new bugs.
Lack of stability in usage : we experience crashes at higher rate than before...
No interest of new features XXX, if the basic features are not stable.

You team are doing a great job, hope you get more chance
to focus on the stability/testing the releases....

@joaoponceleao
Copy link

Jupyter Notebook plugin work, without major issues.

This would be nice in Spyder 5

@mxfm
Copy link

mxfm commented Jan 11, 2022

Hi!

I don't think that creating new issue will suit my case (also, it will be closed anyway), but this thread seems to be appropriate for my post.

My big wish is to fix current broken model of python dependencies which makes spyder unusable on rolling linux distros approximately 20-40% of the time (depends on how packages are updated). The problem is that spyder code devs decided to put restrictions on several python dependecies like 'python-xxx<2.0'. Because these python dependencies are updated quite often, spyder stops to launch each time one of these dependencies are updated to the versions which are considered to new. Because of this the spyder package is often broken. In rolling model linux distros these depencies usually cannot be rolled back. In particular, if new version of the package has major secutiry flaw or regression, this is a valid reason to downgrade package version, but the spyder dependencies policy is not a valid reason (for example, newer versions of one of its dependencies may be required by other packages).
So, in short, because dependencies' version restrictions are too close to current versions and because restrictions are placed on several dependecies, there is significant chance that one of these dependencies breaks its version restriction, and spyder becomes unusable.

@arita37
Copy link

arita37 commented Jan 11, 2022 via email

@steff456
Copy link
Member

Hi everyone!

Thanks for opening this issue @ma-sadeghi, it has been a dream of us to be able to support new programming languages in Spyder but as you all know, we are a small team that has to tackle a lot of other issues as well. Nevertheless, if you are interested to work in an extension for supporting Julia in Spyder, it is possible. Right now I do know that you are able to add Julia's language server to at least have completions in the current version of Spyder without major trouble. I'm not sure what other features you'll like to see, but with the refactoring we've been doing since last year, now it is easier to extend Spyder.

@arita37 it would mean a lot if you are able to track down the stability issues and letting us know how to reproduce them. We will eventually get to fix them and hopefully you will be motivated to use the latest versions of Spyder. About the Jupyter Notebook extension, sadly we haven't been able to update it to the latest changes in the API, if either of you are interested in giving us a hand with that work I'll be happy to guide you through the process.

@mxfm, we have in queue the development of a Linux installer, we are aware that linux distros are not perfect right now, which is why we don't recommend that installation. Hopefully this year we will manage to work into this more.

Thanks guys for letting us know the things that aren't perfect, because in that way we will be able to iterate and make each release better.

@steff456 steff456 self-assigned this Jan 11, 2022
@ma-sadeghi
Copy link
Author

@steff456 Thanks for your reply! Sorry for the confusion.

What I meant was that as amazing as Spyder is, there might be benefits in piggybacking on VSCode's infrastructure. So, my proposal is to keep working on Spyder, but just for maintenance, and put all your energy in creating a nice Python extension for VSCode that focuses on the scientific computing aspects.

A successful example in the past has been Juno IDE, which as I mentioned used to be "Spyder for Julia", but then the developers decided that they can create an extension for VSCode. The major benefit is that they no longer need to worry about the "IDE stuff", but rather they can focus on Julia stuff.

Similarly, if Spyder dev team were to follow a similar model, they could just focus on Python and the scientific computing stuff, rather than the "IDE stuff". Again, I'm not saying that you should abandon Spyder, but just "maintain" it, rather than actively develop it. Finally, this is just my suggestion based on what I observed in the Julia ecosystem.

@arita37
Copy link

arita37 commented Jan 12, 2022 via email

@fohria
Copy link

fohria commented Jan 12, 2022

@ma-sadeghi i'm curious, what is it you think would be gained from spyder devs creating a plugin to vscode? microsoft has their own official python and jupyter plugins for vscode with plots, variable explorer, repl etc. if you think spyder is great already, what would be improved by making a "spyder plugin" for vscode?

@ma-sadeghi
Copy link
Author

@fohria Well, for starters, Spyder is an IPython-first IDE, whereas VSCode is Jupyter-first. I tend to like IPython much more for development. Jupyter is good but mostly for demonstration (my opinion ofc). The other factor, is the IDE-stuff, which is more robust and snappier in VSCode than those in Spyder. Spyder is great, yes, but given the constraints (limited developer time, no monetary returns, etc.).

@ccordoba12
Copy link
Member

ccordoba12 commented Jan 15, 2022 •
edited
Loading

@ma-sadeghi, my comments about your proposal:

  1. From the UX perspective, VSCode lacks the concept of panes that we have, which I think is really neat to organize different kinds of functionality in an IDE. It has three main areas (side bar, bottom panel and editor), so all information has to be accommodated in one of them. I've seen videos of Julia for VScode (for instance) and find really awful that plots are shown in the sidebar and variables as tabs next to editors. At the end, I'd say that shows that a more complex interface is an afterthought in VSCode and it's more confusing than helpful.
  2. Most of the Spyder features (Variable Explorer, Plots, debugger) are already part of the Python and Jupyter extensions provided by Microsoft. So we wouldn't be creating a new extension, just trying to collaborate with them. But some parts of those extensions (like the language server) are not OSS because that's their competitive advantage. Besides, their development team is not part of the Scientific Python community (as far as I know), so they don't understand our use cases and problems very well.
  3. About our IDE features, it's been a long and hard process to stabilize them (two years), but I think we're getting there. I'd say most of them work pretty well now (some have bugs but they are fixable). Now we're improving their performance, which has been our main concern since 5.1.0 (released last July) and will improve even more in 5.3.0.
  4. About our funding, we have a team of four developers working part time on the project hired by Quansight. And we'll probably stay the same at least during one or two more years.

@ccordoba12
Copy link
Member

@arita37, if you're fine with Spyder 3, then keep using it and refrain to post more comments like the ones you posted here (and several times before). They are really discouraging and unhelpful because:

  1. Thanks to the amount of bugs we receive per month here, we're perfectly aware that things have not been working well in Spyder since the release of version 4 two years ago.

  2. There have been two major sources of instabilities in this period:

    • The migration of all our IDE features to the Language Server Protocol (LSP) in Spyder 4, which was absolutely necessary to support folding, formatting, and better linting. That will also allow us to add refactoring and types linting in the future.
    • The creation of a new API in Spyder 5, which allowed us to fix a lot of technical debt we accumulated in the last ten years (yes, Spyder is more than ten years old). That will also help other projects to build their own plugins for Spyder, or even create their own IDEs using Spyder as their foundation.

    This process will conclude in Spyder 6 and then we could focus more on bug fixing than in constant refactoring to either support the new API or LSP features. However, as I said in my previous comment, things are pretty stable now (although not perfect).

  3. You're clearly don't know what you're talking about when you say

    Suggest to use a tool like selenium

    We already have more than 1200 automatic tests that run on Windows, Mac and Linux, with conda and pip packages on every pull request.

@ccordoba12
Copy link
Member

ccordoba12 commented Jan 15, 2022 •
edited
Loading

@mxfm, you said:

My big wish is to fix current broken model of python dependencies

Sorry but I totally differ here. I fail to see how adding upper constraints to dependencies is "broken". In my opinion, the model that is broken for packages like Spyder is the one of rolling release distros. Since we're a small team, we can't afford to test everything against the master branch of all our dependencies (which are about 40 at the moment), just to satisfy the expectations of ~1% of our users (assuming ~5% uses Linux in total and of those a 20% uses rolling distros). Instead, we prefer to add constraints, so we don't have to rush and release a new fix every time something breaks (which is very frequent).

And even then, sometimes it can take us months to support a new version. For instance, just in Spyder 5.2.2 (to be released next week) we will be able to correctly support IPykernel 6 and Jupyter-client 7, released more than six months ago.

which makes spyder unusable on rolling linux distros approximately 20-40% of the time (depends on how packages are updated)

If you know that Spyder is unusable or unstable with the packages provided by your distro, then stop using them (I really don't know what else to say, you're admitting the fact). Spyder is stable and works perfectly fine when installed with conda or pip in a virtualenv (well, almost in the last case, but that's not our fault).

If you need desktop integration and that's why you use your distro packages (the only reason I can think of), then you can take our desktop file and adjust it to use your virtualenv:

https://github.com/spyder-ide/spyder/blob/master/scripts/spyder.desktop

Then you wouldn't notice a single difference between distro and conda/virtualenv Spyder. Instead, you'd be working with a version that wouldn't give you dependencies headaches at all.

So, in short, because dependencies' version restrictions are too close to current versions and because restrictions are placed on several dependecies, there is significant chance that one of these dependencies breaks its version restriction, and spyder becomes unusable.

Comments like this clearly show that you have not developed an OSS project at the scale of Spyder. Else you wouldn't be making these outlandish propositions just to benefit a really small amount of users.

@ccordoba12
Copy link
Member

@joaoponceleao, you said:

Jupyter Notebook plugin work, without major issues.

This would be nice in Spyder 5

That will be fixed in the first half of this year. Unfortunately, the person that maintained that plugin became busy with other things and we haven't had time to update it to Spyder 5.

@joaoponceleao
Copy link

That will be fixed in the first half of this year. Unfortunately, the person that maintained that plugin became busy with other things and we haven't had time to update it to Spyder 5.

That's great news. Personally I find Spyder more stable than VSCode, but with a less useful editor (no multi cursors...). I hope Jupyter notebooks becomes a first class citizens in Spyder (hint... not a plugin ;-)). I've never been a big fan of them but the larger the project gets the more useful it is to be able to see the plots and data without having to rerun the whole thing. A good notebook environment within Spyder (or something else that provides quick access to previously generated outputs) would be useful for data science.

@ccordoba12
Copy link
Member

I hope Jupyter notebooks becomes a first class citizens in Spyder (hint... not a plugin ;-))

That's the plan in the mid-term (i.e. next year and a half or so). Spyder-notebook was an experiment to see if we could integrate the notebook with Spyder. Although we proved it was possible, we discovered our initial (and current) approach has several usability issues that required a new API to properly address them. Now that we have it, we can proceed to fix those issues and officially integrate it with Spyder.

@ccordoba12 ccordoba12 self-assigned this Jan 16, 2022
@arita37
Copy link

arita37 commented Jan 16, 2022 via email

@ccordoba12
Copy link
Member

ccordoba12 commented Jan 16, 2022 •
edited
Loading

Thanks for your kind words @arita37! And sorry if I was harsh in my response. It's just hard to constantly hear that, even after hundreds of ours of hard work, things are still not stable (the problem is that they really can't be right now due to reasons I mentioned above).

@arita37
Copy link

arita37 commented Jan 16, 2022 via email

@mxfm
Copy link

mxfm commented Jan 16, 2022

@ccordoba12

Comments like this clearly show that you have not developed an OSS project at the scale of Spyder. Else you wouldn't be making these outlandish propositions just to benefit a really small amount of users.

Frankly, I expected answer like this ("we, developers, know better and are more competent") and sticking to 'Windows centric' attitude toward software distribution.

You think that Spyder is large project and therefore exceptional, but rolling release linux distros host thousands of programs, including very complex software, much more complex than Spyder - all work nice. In recent years I used dozens of programs, including relevant to statistics and data science - python, R, tensorflow, pytorch, also different IDEs in rolling release model. None of them are currently broken and none were broken in my memory as much as Spyder for the last decade or more (which is sad, because except software distribution problem Spyder is nice). You may not care about 1% users on rolling release distros, but many complex projects do work in rolling release model. Why there are no other projects which impose such close to new versions restrictions on multiple dependecies?

@arita37
Copy link

arita37 commented Jan 16, 2022 via email

@arita37
Copy link

arita37 commented Jan 16, 2022 via email

@mxfm
Copy link

mxfm commented Jan 16, 2022 •
edited
Loading

@arita37

I understand about funding. I would accept the answer that "1% user base is not worth out efforts considering other project goals". I just want to point out, that supporting large project in rolling release distro is doable, there are no technical limitations for this, there is nothing wrong with rolling release distros.

@arita37
Copy link

arita37 commented Jan 16, 2022 via email

@ccordoba12
Copy link
Member

ccordoba12 commented Jan 17, 2022 •
edited
Loading

To @mxfm,

Frankly, I expected answer like this ("we, developers, know better and are more competent") and sticking to 'Windows centric' attitude toward software distribution.

At no point I said that we know better and that we only support a Windows distribution model. Since it seems you didn't understand my previous points, let me repeat them again:

  1. I clearly explained why we're unable to support the rolling release distros model:

    Since we're a small team, we can't afford to test everything against the master branch of all our dependencies (which are about 40 at the moment)

    If you're willing to invest the necessary time to expand our test suite to run against the master branch of our dependencies (and probably some of their dependencies as well), and also to fix the problems detected by it as soon as they appear, then we will be happy to support rolling release distros.

    Otherwise it's impossible for us to do that due to this reason

    we prefer to add constraints, so we don't have to rush and release a new fix every time something breaks (which is very frequent).

    The problem is we integrate very closely with some of the packages we depend on, so some of the functionalities we provide break very frequently when new versions of them are released. When that happens, we can receive up to 100 issues per week of people complaining about it. So, in order to avoid that and ensure Spyder's stability, we have to add upper constraints.

  2. Since it seems you don't have experience with something like that and don't understand what it'd cost in time and amount of work, but instead you're just asking that Spyder must work with your distro, I find your proposition simply outlandish.

You think that Spyder is large project and therefore exceptional, but rolling release linux distros host thousands of programs, including very complex software, much more complex than Spyder - all work nice. In recent years I used dozens of programs, including relevant to statistics and data science - python, R, tensorflow, pytorch, also different IDEs in rolling release model.

I'm not saying that rolling release distros are bad (as a matter of fact, I used Gentoo for several years). Please read my words again

In my opinion, the model that is broken for packages like Spyder.

This means packages like VSCode and Rstudio.

None of them are currently broken and none were broken in my memory as much as Spyder for the last decade or more (which is sad, because except software distribution problem Spyder is nice).

That's because Spyder is not packaged correctly in rolling release distros. Look at how VSCode and RStudio are distributed in Arch:

So, instead of forcing these very complex applications, that depend on hundreds of packages between direct and transitive dependencies, to use the distro packages, they are distributed as binaries in a single package. Can you image what it would be to track every npm package that VSCode depends on, add it to Arch and force it to work with them? And not with the versions required by VSCode in its package.json, but with the latest versions of all of them? Then, I'm sure VSCode on Arch would be very unstable and really awful to work with.

Well, that's exactly the same thing that they are doing with Spyder. They are trying to force it working with a set of dependencies it's not prepared for. That's why it's so broken, as you noticed.

Even more, although Linux maintainers are well intended, sometimes they are clueless about how Python packaging works at a deeper level. For instance, look at these issues:

You can see that they don't understand what an extra requirement means and how it works.

You may not care about 1% users on rolling release distros, but many complex projects do work in rolling release model. Why there are no other projects which impose such close to new versions restrictions on multiple dependecies?

Frankly, I think the maintainers of your distro are not doing things correctly by making their users believe that Spyder can be installed through its package manager, when in reality they are distributing a broken package.

And about that statement, I have evidence too. The Debian maintainer opened like 15 bugs last December about errors in our test suite when he tried to run it on their CI infrastructure. Some were simply to solve, but others will take us months of hard work and are very serious. So he opted to wait until that work is finished before proceeding (which I'd say is the right attitude).

So, instead of complaining here about a problem which is not our fault at all, please post it in your distro issue tracker and let them know about all the problems they are creating for Spyder. If you manage that they listen and remove Spyder from their list of packages, or wait until all our dependencies match the ones on their repos, that would be a great help.

The other solution would be to install a self-contained Spyder package (like the VSCode and RStudio binaries). And that's what we'd like to provide, as @steff456 mentioned before, but we haven't had time to do it, sorry.

@ccordoba12
Copy link
Member

To @arita37

Not sure the best way,
What about 2 USD or 5 USD one time payment
with easy to pay system ?

We have Open Collective for that

https://opencollective.com/spyder

Maybe, you have some concrete ideas
how to support spyder project,
besides just criticsm because of a
free of cost project…

Well put @arita37! Just coming here to say "why does not Spyder work with my distro?" is very unhelpful as well.

Would suggest to a poll to the users
to have better understanding :

How people use Spyder ?
Why they prefer Spyder to another IDE
when using it ?
What they expect in the future ?

That's a good idea, thanks!

So, providing actual recipes/details
for a problem is more helpful
than just pointing some “lack of…”

Thanks again! I think that's the right attitude.

@arita37
Copy link

arita37 commented Jan 17, 2022 via email

@jitseniesen
Copy link
Member

That [Jupyter Notebook plugin] will be fixed in the first half of this year. Unfortunately, the person that maintained that plugin became busy with other things and we haven't had time to update it to Spyder 5.

That person is me and I should be less busy in the coming months. I am hopeful that I can update the notebook plugin next month (February) and release a version that works with Spyder 5.

@evert-mouw
Copy link

Support for Julia would attract more users now that Julia is growing. I agree with @ccordoba12 that from a UX perspective, Spyder is better than VSCode for data science. Julia and Python are behaving nice to each other (and exposing their libs & data structs) but I understand such deep integration would require a lot of work. OTOH, this isn't too bad either if you don't have much development resources: https://www.julia-vscode.org/

Anyhow, I'm not involved much, just wanted to express my respects to this project.

@ccordoba12 ccordoba12 mentioned this issue Apr 10, 2022
Closed
2 tasks
@raphaelquast
Copy link

Hey all, since I've been a long-term user of spyder for many years now and I accidentally stumbled upon this issue, I just wanted to put a comment here...

I've tried Atom, Vscodium and other editors, but none of them comes close to the usability that spyder provides when working in pure python. I think that this is a really strong point for spyder (and the reason why in the end I always come back and never regret it😄).

Let me highlight some of the points I particularly enjoy:

  • direct integration with conda (a simple conda install -c conda-forge spyder is all I need to do to install the editor AND configure it to work with the current environment
  • customizability (all panels can be placed anywhere)
    • possibility for multiple separate windows (in addition to split-panels)
  • the "Help" panel in conjunction with cntrl + i
  • ... then there's of course the awesome IPython console that does its job really well and facilitates a certain "python-coding-workflow" that is not always easy to set up with other editors
    • interactive matplotlib pots
    • possibility for remote kernels
    • variable explorer and a nice debugger that also hooks in on any manual call to pdb.set_trace()

Things I'd like to see in "future" spyder (some of them were partly existing in Spyder3 but vanished since then...):

  • GitHub integration (I know that's a big one but it would be awesome)
  • Better control for projects (especially multi-folder projects)
  • maybe some kind of re-structured text (sphinx) and markdown preview?
  • maybe some basic support for jupyter notebooks?
  • ... and as a personal opinion... I'd avoid the plots-pane... it takes away the fun of matplotlib (seriously... I don't get why anyone would prefer a static low-quality png over an interactive zoomable widget that can be saved as png any time)

Finally, I wanted to say that even though the spyder-team is probably very small, responses on GitHub have always been quick, nice and helpful... I don't even know where to start asking for things when it comes to other editors backed by big companies that are usually so feature-rich that I get lost in the possibilities without ever finding what I'm searching for.

Don't get me wrong here, vscode is awesome if you need to use other programming languages than python, but having a dedicated editor that has been optimized for python is just so much more convenient than some allround-tool that takes hours to configure...

@dalthviz
Copy link
Member

dalthviz commented Apr 20, 2022 •
edited
Loading

Hi @raphaelquast thank you for your feedback and constructive opinion! Regarding the future items you mentioned:

GitHub integration (I know that's a big one but it would be awesome)

Maybe a look to the spyder-vcs plugin could be interesting for you (not a package yet but maybe you could try it from source and help testing it): https://github.com/spyder-ide/spyder-vcs

Better control for projects (especially multi-folder projects)

Indeed, projects functionality could be highly improved and most probably the code needs a refactor to be more extensible

maybe some kind of re-structured text (sphinx) and markdown preview?

I think we have an external plugin for something like what you mention, spyder-reports. However it needs to be updated to be compatible with Spyder 5 (I'm not totally sure if it's even compatible with Spyder 4) and in general needs a revisit (it has around two years without further development!): https://github.com/spyder-ide/spyder-reports

maybe some basic support for jupyter notebooks?

Actually we have an external plugin for basic usage of jupyter notebooks inside Spyder, spyder-notebook. However it also needs to be updated to be compatible with Spyder 5: https://github.com/spyder-ide/spyder-notebook

... and as a personal opinion... I'd avoid the plots-pane... it takes away the fun of matplotlib (seriously... I don't get why anyone would prefer a static low-quality png over an interactive zoomable widget that can be saved as png any time)

I think for a good a mount of users the plots plugin has been a really good addition even with its shortcomings but we have thought about what you say with other core developers and at least some UI/UX improvements could be done (I think we have some issues for it at the ux-improvements repo: https://github.com/spyder-ide/ux-improvements/issues).

However, having another plugin to visualize interactive plots (and not just for matplotlib but probably for a more general kind of plots which are web based) could be nice, but that is quite a big project, so most probably we will need some funding for that to have someone working on it full time I believe.

Hope this gives you a more clear view about things around Spyder at the moment @raphaelquast and if you want to help with something let us know :)

@raphaelquast
Copy link

raphaelquast commented Apr 21, 2022 •
edited
Loading

Hey, @dalthviz thanks for the response, quite illustrative indeed! I think reviving the notebook plugin would really round up spyder's position as an allround python IDE.
Concerning contributions I am unfortunately quite limited with my time at the moment... so I'm stuck to using spyder instead of contributing to its development 😅 but I'd be happy to try the spyder-vcs plugin and provide feedback (I'll need some manual on how to set it up... the GitHub readme is quite empty...)

@dalthviz
Copy link
Member

dalthviz commented Apr 21, 2022 •
edited
Loading

No problem @raphaelquast ! Just testing things is a huge help and contribution! In particular for the spyder-vcs plugin you can install it with pip from the repo with something like pip install git+https://github.com/spyder-ide/spyder-vcs.git@main. Also, to test it, I would suggest for you to create a new python environment with the latest Spyder (5.3.0) from pip. So if you are using Anaconda, running from an Anaconda prompt something like this:

conda create -n spyder-vcs-test -c conda-forge python=3.9
conda activate spyder-vcs-test
pip install spyder==5.3.0
pip install git+https://github.com/spyder-ide/spyder-vcs.git@main

Maybe opening an issue in the spyder-vcs repo to put some instructions like the ones I mentioned here could be worthy too. As far as I checked the plugin works along side the projects functionality. So basically a new pane to manage the project version elements should appear and show options when you have a spyder project open that also is a git repo

@raphaelquast
Copy link

Thanks! I've set it up and it seems to work fine! I'll report to the spyder-vcs repo once I had a thorough look at it!

... concerning re-structured text/sphinx support...
I noticed that the only thing that actually keeps me from using spyder for sphinx documentations is the missing language-support for markdown/rst (e.g. linting/syntax highlighting)

Aside of that using !make html from the ipython console and viewing the rendered docs with python's native local webserver (python -m http.server actually works like a charm...

@dalthviz
Copy link
Member

Thanks! I've set it up and it seems to work fine! I'll report to the spyder-vcs repo once I had a thorough look at it!

Awesome! Thank you for taking the time to check it out 👍

... concerning re-structured text/sphinx support...
I noticed that the only thing that actually keeps me from using spyder for sphinx documentations is the missing language-support for markdown/rst (e.g. linting/syntax highlighting)

That's one thing we have also discussed in the past and it's the reason why we started working in https://github.com/spyder-ide/pysyntect . However, before changing the syntax highlighting functionality there is a refactor for the Editor to be done (to decouple it from other panes/plugins/functionality like the work being done in #17467, make it use the new plugin's API and try to improve its performance). So that will take a good amount of time but is something we think could be nice to have eventually :)

@ccordoba12 ccordoba12 mentioned this issue Feb 10, 2023
Closed
3 tasks
@raphaelchinchilla
Copy link

Hi all,

I wanted to get back to the original comment that @ma-sadeghi made about two years ago (things got a bit tense there in the middle, which unfortunately changed the tone of @ma-sadeghi original's post).

I have been using Spyder as my Python IDE for more than 10 years and I love it. It is the best Python IDE in the world. It does everything that it does not just well, but perfectly. Anyone that is doing science in python should use Spyder.

Unfortunately, continuing to use Spyder is becoming harder. VS-Code has become so ubiquitous that I now use it for everything (Latex, Markdown, Julia, C/C++) except for local development in Python (remote development is much better supported by VS Code, even though I know Spyder is working hard on that right now). Now with Github Copilot available and so well integrated with VS Code, I am not sure how long more I will stay in Spyder.

And this is really a shame, because Spyder is the tool for Scientific Python. The Python VS Code extension has a "Interactive Mode" but it is just a stripped down version of Jupyter Notebook. It does not support plotting in a separate pane, it does not have a ipdb based debugger (no post mortem, no ipython kernel during debugging, no option to change the commands such that they have to start with "!" to avoid clashing, etc), and the look-and-feel of the REPL is bad (because it is not a REPL, it is a strip down Jupyter).

The internet is full of comments of people asking for some of the functionalities of Spyder in VS Code, but the VS Code developers do not seem to see the appeal (maybe because they gear more towards software engineers than to scientist).

There are several VS Code extensions that try to provide better IPython support, the currently best maintained seems to be ipython by Hoang Kim Lai). With this one, it is actually possible to use IPython fairly well, but it does not have the variable explorer and several of the other layers that Spyder provides, and there are some issue with plotting on MacOS (or on remote machines).

I don't know what is the point of this post, except maybe to bring back the conversation that @ma-sadeghi brought two years ago. My dream would be to have a Scientific Python extension, possibly developed in tandem with Spyder. Maybe a good start would be to figure out a good way to have the spyder-kernels to integrate with the VS Code console.

@ccordoba12
Copy link
Member

ccordoba12 commented Feb 26, 2024 •
edited
Loading

I have been using Spyder as my Python IDE for more than 10 years and I love it. It is the best Python IDE in the world. It does everything that it does not just well, but perfectly. Anyone that is doing science in python should use Spyder.

Thanks for your kind words @raphaelchinchilla!

Unfortunately, continuing to use Spyder is becoming harder. VS-Code has become so ubiquitous that I now use it for everything (Latex, Markdown, Julia, C/C++) except for local development in Python (remote development is much better supported by VS Code, even though I know Spyder is working hard on that right now). Now with Github Copilot available and so well integrated with VS Code, I am not sure how long more I will stay in Spyder.

Ok, that's sad to hear although we're planning to have Copilot integration in the mid-term.

The internet is full of comments of people asking for some of the functionalities of Spyder in VS Code, but the VS Code developers do not seem to see the appeal (maybe because they gear more towards software engineers than to scientist).

No surprise there (see point 2. of my comment above).

I don't know what is the point of this post, except maybe to bring back the conversation that @ma-sadeghi brought two years ago. My dream would be to have a Scientific Python extension, possibly developed in tandem with Spyder. Maybe a good start would be to figure out a good way to have the spyder-kernels to integrate with the VS Code console.

We're not opposed to having that extension, but (sorry to say it) we're not going to contribute to it. As I mentioned in the same comment I just referenced, we don't think VSCode provides the right graphical elements in its interface that something like Spyder requires. And even if it did, we know very little Javascript/Typescript to reimplement Spyder's functionality using those languages.

@mattcbro
Copy link

I also am forced to use VSCode because of it's "ubiquitious" nature. However it's a huge step down from Juno. The UI is absolute trash. You can't find any commands in the menu very easily and have to learn magic character codes to do things like launch a REPL or find settings etc.

I always forget the magic ctrl-shift-P command to start the command list. The debugger for Julia is slower, less intuitive and you have to click and type a horrendous amount of garbage to step through your code. I'd love a Spyder version of Julia or a decent IDE that doesn't involve the "microsoft" way of obfuscated and random ui commands.

@ccordoba12
Copy link
Member

You can't find any commands in the menu very easily and have to learn magic character codes to do things like launch a REPL or find settings etc.

I share the sentiment. I don't think VSCode is quite user friendly.

I'd love a Spyder version of Julia or a decent IDE that doesn't involve the "microsoft" way of obfuscated and random ui commands.

We've had the same request a few times before. The main problem is we don't use Julia at all.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@ccordoba12 ccordoba12

@steff456 steff456

Labels
status:Awaiting Followup
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests