Write documentation on how to install packages that can be imported in Spyder

[ccordoba12]

This is a common problem for users, e.g.

https://stackoverflow.com/questions/50913242/issue-importing-keras-in-spyder-and-jupyter

This will be solved in Spyder 4, but in the meantime we can help users with this.

[CAM-Gerlach]

Is the user's problem that they are installing them into the wrong environment, or if not, what's the solution I'm supposed to be writing about? Sorry, I'm not 100% familiar; I know I've helped users in the past with related issues but I don't use keras myself atm and I want to be clear on the canonical intended solution/procedure here.

virtualenv "anacondaEnvironment"

?!?

[ccordoba12]

Is the user's problem that they are installing them into the wrong environment

Yes, this is the main problem: they install packages in different conda/pip envs and expect Spyder to find them without further configuration.

what's the solution I'm supposed to be writing about?

I'd like a page or link to point to our users with these possible solutions:

1. Install spyder-kernels on their env, Identify its Python interpreter and change Preferences > Python interpreter to point to it.
2. Install Spyder on their env and run it from there (this should be gently discouraged because it's a waste of resources).

I decided not to answer any of these questions in SO because it's really time consuming to repeat the same speech again and again. Besides, before we didn't have spyder-kernels (which makes things far more easier).

[ccordoba12]

More posts about this (I'm listing them here so we can give an answer once we have a link in our docs):

https://stackoverflow.com/questions/50967252/python-spyder-cant-import-installed-pyuserinput-packages

https://stackoverflow.com/questions/50976221/caffe-module-not-found-error-in-spyder

[CAM-Gerlach]

There was also at least one person in our Gitter chat very recently with a very similar issue. I could prep something to be ready to merge after spyder-ide/spyder#7306 is, but I'd rather wait until that is final so I can walk through the steps myself to make sure what I write works and is accurate.

[ccordoba12]

https://stackoverflow.com/questions/51006705/tensorflow-only-works-in-terminal-but-not-in-python-ides

[ccordoba12]

https://stackoverflow.com/questions/51107665/feedparser-module-is-not-importing-from-spyder-ide

[ccordoba12]

https://stackoverflow.com/questions/51117768/sklearn-doesnt-exist-within-spyder-ide-but-does-exist-when-running-from-the-ter

[CAM-Gerlach]

@ccordoba12 Really sorry for the delay. I created this wiki page describing the process as I'm aware of it for the time being, and welcome your input and corrections. In short form, it would be a great candidate for the future website FAQ, with a link to the full wiki version. I don't want to fragment our documentation any more than it already is (docs, wiki, website, Spyder repo readme/contributing, tutorial, etc) but I'm not sure exactly where it would fit within the formal docs right now, since our flat hierarchy is already getting pretty long. Ideas?

[ccordoba12]

Thanks for your help with this one! I'll review it when I have some time.

---

Ideas?

Let's leave it in our wiki for now since the process is going to change (and it'll be greatly simplified) in Spyder 4.

[ccordoba12]

Besides, at that point we could add this explanation to our Projects page here, which would fit well with the rest of our docs.

[CAM-Gerlach]

Okay, great! Thanks.

[ccordoba12]

https://stackoverflow.com/questions/51351785/importing-pandas-datareader-in-spyder-python-3-6

[CAM-Gerlach]

FYI, I just updated the wiki page with a detailed note about making sure you have the correct version of spyder-kernels for your Spyder version.

[ccordoba12]

Great, thanks!

[CAM-Gerlach]

Should we now close this issue?

[ccordoba12]

Please leave it open until I review the wiki page. Then I'll close it.

[CAM-Gerlach]

Oh, my bad. I somehow forgot you hadn't done that yet!

[ccordoba12]

https://stackoverflow.com/questions/51392108/error-on-import-glpk-in-spyder-after-downloading-in-anaconda-prompt

[CAM-Gerlach]

@ccordoba12 Thanks for your additions; I had no way to know they were there until now. I cleaned up some of the prose and clarified a number of things that were unclear, but overall the quality was very good, and a big further improvement from your previous work and few of the changes were grammar/syntax/style issues and most just clarifying the content itself.

Also, FYI, I had no idea you made those extensive additions and edits until I manually checked the page now to update something else, since Github wiki doesn't notify users of changes and nothing was posted here. If we're in a situation like this again in the future, if you could notify me in the thread here that would be great. Thanks!

[ccordoba12]

Sorry for not letting you know about it. I was hoping to do a second round of edits to my initial contribution, but life always get in the way.

[CAM-Gerlach]

@ccordoba12 Ah, no worries. I know that happens to me too, for sure :) And most wikis notify the creator of a page if it is modified, which Github wiki doesn't.

[CAM-Gerlach]

@ccordoba12 Just so we're on the same regarding the plan for closing out this issue: So you'll make those further edits, I'll review, and then you'll confirm and finally close?

[ccordoba12]

There's one important thing I want to do right now: I want to move the first section (Installing packages into the same environment as Spyder) to the end (as it was before).

What I want is for people to find right at the beginning an explanation to the problem they most commonly face (The most common problem: Using newly-installed packages inside Spyder) and then a solution for it (Working with other environments and Python installations).

[CAM-Gerlach]

@ccordoba12 Okay, from that perspective if its mostly just going to be used as an answer to a specific set of SO questions rather than more generally on its own, then I guess it makes sense to have it after the section specifically explaining that problem. I'd suggest (and implemented for now) putting it right after the "most common problem" section, which ends with the paragraph explaining the two main approaches to addressing it, since it essentially briefly explains how to achieve the first mentioned approach, which is the simplest and most conventional setup that most users start with (just one environment for both Spyder and packages) and explains the baseline configuration, and then is immediately followed by the much larger section explaining the second mentioned approach (with its two sub-approaches).

This compromise, I think, is better than sticking it all the way at the end, for a few reasons:

• It is the order readers expect from the listing at the end of "the most common problem" section, making for a good flow and easier navigation
• The "same environment as Spyder" section is basically useless all the way at the end, since it is very out of place there and doesn't relate to anything else near it and so likely won't be found by those looking for it and could confuse those who aren't
• It follows the principle of starting with the simplest and most conventional/default approach, and then proceeding to more complex solutions
• It also helps further explain the problem, by helping them further understand the "default" situation and how they have departed from it, more detail about environments and in which one Spyder can be found, and therefore belows closer to the top

[ccordoba12]

I'd suggest (and implemented for now) putting it right after the "most common problem" section, which ends with the paragraph explaining the two main approaches to addressing it, since it essentially briefly explains how to achieve the first mentioned approach

Ok, that makes sense. But although it's the easiest one right now, I'd want to start deprecating it since Spyder 3 so we can move to the better approach we're planning for Spyder 4.

That's why I'd like to put it at the end. What do you think?

[CAM-Gerlach]

But although it's the easiest one right now, I'd want to start deprecating it since Spyder 3 so we can move to the better approach we're planning for Spyder 4.

Isn't it installing a separate copy of Spyder into every environment when working with multiple that you want to deprecate (i.e. "The easy approach", rather than the single-environment case? For many simpler/specific use-cases as well as for new users, particularly if working with just the default Anaconda packages that are already installed, keeping both packages and Spyder in just one environment; that is the default after all and probably what most users are using and will continue to do (that's basically what I had on my work machine for a year, since almost all my efforts were focused on one core project while I was there).

Of course, it is use-cases that require more than one environment with Spyder, then we recommend users keep Spyder installed in one and use spyder-kernels in the rest rather than installing Spyder more times, but for only one environment to begin with (and no esoteric packages) it is not as compelling of a case to create and setup a whole separate one and configure Spyder accordingly, since it is way less "lightweight" than the alternative in this case and the only gain is a modest to minimal one in package isolation. Furthermore, we'd be basically "deprecating" the Anaconda default.

Also, I'd think it is more user-friendly to clearly mark deprecated approaches as such, include language explaining why encourage users to move away from them, rather than just bury them at the bottom (particularly when said approach explains the default setup that is likely retained by the great bulk of our users). I can add some stronger language accordingly.

[CAM-Gerlach]

Implemented as proposed above; let me know what you think.

[ccordoba12]

https://stackoverflow.com/questions/51679235/modulenotfounderror-no-module-named-selenium-error-despite-having-downloaded

[CAM-Gerlach]

@ccordoba12 Any luck reviewing this?

[CAM-Gerlach]

@ccordoba12 Any chance of getting a review so we can close out the v3.3 milestone, and make sure it is correct for the many users we are already sharing it with?

[ccordoba12]

I just did another review. Changes are minimal, but please review again.

[CAM-Gerlach]

Thanks, and sorry for the delay—I had the diff open but must have accidentally closed it. All your changes were fine, except a few places where I made long-winded section references into embedded intra-document links. I also re-wrote the "If the resulting paths are different" section to give a one line summary of all three choices and one line on the advantages/disadvantages and use case for each, with links to the relevant section for each; take a look at that to make sure you like it.

[ccordoba12]

Nice!! Thanks a lot for your final changes.

I think this one can be finally closed.