Add menu to change console environments #10
Comments
|
@CAM-Gerlach what do you think about this? We are going to continue this discussion further so let us know what are your ideas for this. |
I thought we were all going to have a meeting about this to discuss it? Overall, the root of the confusion we're grappling with here is how to best present two distinct concepts: the environment of the currently selected console, and the environment that new consoles open in, which related to two different common user tasks: determining what environment their current console is using, and opening a new console in a specific environment. After considering several approaches, I think the best way to both make this difference clear while offering an efficient, discoverable and easy to use UX is to separate them in the UI, putting each in a place appropriate to the task users are trying to accomplish, which closely matches both @mrclary 's and my proposals on spyder-ide/spyder#12200 . Breaking them down one by one: Opening a new console in a specific environmentWhen (and only when) the user is opening a new console, they need to know what environment it will be opening in by default, and have a way to easily select a different one, as they may be opening several consoles in different environments or want to open one console in a specific environment, without changing the default. Current proposalsCurrent UX:
Initial spyder-ide/spyder#13950 proposal:
@isabela-pf proposal:
Recommended approach
Checking the current environmentWhen the user is working in a given console, they may want to check the current environment they are using. I'm not sure how necessary offering a menu to change it is, since as it would have to kill the current kernel and launch a new one, losing all of the user's variables and packages (unless we automatically save and restore the user's session), it has essentially the same effect (and the same number of clicks) as opening a new a new console in that env and closing the old one, but it could be a little more intuitive for users. Current proposalsCurrent UX:
Initial spyder-ide/spyder#13950 proposal:
@isabela-pf proposal:
Recommended approachUse the above proposal, just without the Default menu (which is handled separately, per the above), and with the env type, name and interpreter version shown for each env, as in spyder-ide/spyder#13950 and as @mrclary and others have proposed. @mrclary , thoughts? |
|
@CAM-Gerlach, If I follow everything correctly, then I think I agree with your assessment. I believe this would be the summary of your proposal. Checking the current environment
Opening a new console in a specific environment
Run configuration per fileWe have not discussed what to do about per-file run configurations, but currently we can set this to "Execute in current console", "Execute in dedicated console", or "Execute in an external system terminal". Under the existing and proposed paradigms, files executed in dedicated consoles can only use the designated default environment. I think we should consider updating this setting to include a selected environment to be used. I also think we should consider adding a setting at the project level, i.e. opening/switching projects opens consoles in the chosen environment. The environment would be set, in decreasing order of precedence, file -> project -> Spyder preferences. Regarding the path display of environments in Preferences, I think that @steff456 is currently revising that to be more readable (i.e. type, name, version). |
|
Yep, thanks @mrclary . That pretty much sums it up, with a few small notes (below).
Yeah, I don't really see the need for per-console environment switching in the status bar; the utility is pretty marginal, potentially confusing and it doesn't feel intuitive to have commands in the status bar affect a specific console (especially a destructive action like this). I mainly included it because it was in your original proposal, so I figured you had a use case in mind.
Unfortunately, many users are unaware of keyboard shortcuts or even don't like to use them at all, especially newer users likely to be potentially confused or intimidated by a list of environments to choose from. Therefore, I suggest retaining the existing separate top-level menu item to open a console in the default environment, to make it easier and more obvious to access, which is reflected in my mockup screenshot above. Also, how would you suggest clearly indicating the default environment in the list?
I definitely agree, we need to add that at some point, and as mentioned default environment is an ideal example for a project-level setting—I'm just not sure of the implementation status of the project improvements necessary for that, which you probably are more so than me.
I see; this might already be in work, but especially if we make this change, we should revise the UI text in the preferences to eliminate the "default" wording for the build-in environment and just call it "same as Spyder", to avoid confusion with the default interpreter for new consoles (which this option is selecting) as well as the system, Anaconda, etc. default Python environment. |
Sometimes I spitball ideas...doesn't mean they are good ;-)
I think this is just fine.
Usually, defaults are indicated with an asterisk |
|
Replying to the meeting we had a few weeks ago, I generally agree with this, but I think there is some more work to be done around how information is communicated to the user.
Below are some very rough ideas on what could be useful to add. If we are going to have a potential split on how environments are applied, it would make sense to specify the different ways it influences the interface. I think this could be as simple as adding a syntax highlighting label to the status bar to show which environment the editor is currently relying on. This could also be communicated through some kind of icon in the console tab. Something like this could make it easy to skim and quickly find which editor and environment are linked. I also agree with the idea that changing the default environment should take more intention and happen in Preferences, though I don't know if it belongs in an existing section or if there should be a new section to accommodate this. |
Since this is handled by the LSP server, would it make sense to just append the LSP status with the environment used for completions/syntax? E.g. "LSP <language>: <env>" -> "LSP Python: conda: base (Python 3.7.6)"; it also seems redundant to have "ready" indicated since if LSP is not ready, then it either has a spinning wheel or indicates error. |
|
Sorry I wasn't able to make the meting this morning; morning storms from the ongoing severe wx outbreak in MS and AL knocked out power and internet shortly beforehand. EDIT: Also, realized I never actually submitted this before I headed out on a research deployment.
Overall, that seems like a fair solution, with some refinements. Actually, its not syntax highlighting that uses this, but LSP services, most notably code completion, so we'd want to change the UI text accordingly (maybe "Code completion:"? But I'm not sure users would understand what it entails, though a tooltip, e.g. "Python environment used for providing code completions", might help). Also, the status bar in the mockup is getting quite long and complex. However, assuming we go with your excellent idea to simply label each console tab with its environment rather than change the status bar indication to show the console env (which I think we all agree on, makes more sense conceptually, is clearer for users and is simpler to implement), the environment already shown in the status bar is the Editor completion/etc lookup environment (in the current working proposal you reference above, the default env for new consoles, which may or may not be the same depending on what we decide, is already shown the one place it matters, when creating a new console in the default env), so we could either:
I initially considered the latter due to being even shorter, but I'd lean toward the former, for the reasons discussed below
The main issue I see with this with this is it makes the status bar indication rather long and syntactically complex, i.e.
Yeah, but it provides a positive indication that LSP should be functional, as is done in the statusbars of other applications, at least on Windows (users may not just assume this if nothing is shown), and something would still be shown if it is restarting or here is an error, taking up as much if not more space. So not sure its worth it.
This is actually how it always has been, though a number of improvements have been made in recent versions; see |
|
I agree with @CAM-Gerlach regarding the general principle of consolidating the statusbar items, where possilbe. I think we both agree that the LSP server status is the right place to put the completion environment details. However, I think that there needs to be clear communication about the console environment; a simple icon in the console tab will not be sufficient. Even if it clearly communicates that it is the "default" environment, I won't remember what that environment was, especially when working with multiple environments. If we agree that a document should be linked to an environment, should we consider segregating the status bar into editor an console sections? Or should the Editor and Console widgets have their own statusbars, apart from the application statusbar? |
|
@mrclary Sorry if I wasn't clear. What I was proposing was:
We do need to decide whether the Editor's completion env should follow the active console, or always default to the current default env set it preferences (which in the future will be configurable per-project). The former matches how the Editor runs files; they are sent to the active console, so we might already expect the user to have selected an appropriate console with the packages present to run their code, and is arguably the best heuristic we have to choose the most likely desired environment to get completions in, rather than whatever is the default selected in preferences, for users working in multiple at once. However, there were concerns related to latency switching between them, explaining this to users and matching user expectation, and its also more complex/more of change to implement. Regardless, the approach suggested above works for whatever we decide on that.
I neglected to directly respond to it above, but I definitely agree the icon in the console tab is confusing—in fact, I'm not really sure what it is even intended to mean at all. If its the default env for new consoles, or the Editor's default completion env (presuming we keep the latter fixed in preferences, all) some or none of the currently open consoles could have this env, so users cannot rely on it being present nor indicate anything meaningful. Meanwhile, if it is supposed to indicate the completion env and we have that follow the active console, it is redundant with the already prominent indication of the active console tab. Either way, unlike UI text in the statusbar, I'm not sure it provides any additional value in actually telling the user what it means, and may in fact mislead more savvy users (those likely to get anything out of it) into thinking Editor completions are looked up dynamically in the indicated console instead of statically in whatever environment that console happens to correspond to (although I have heard plans to eventually do the latter). |
My only concern here is cluttering the console tab, particularly for "Execute in dedicated console" where the document name is listed in the console tab.
I'm not sure what your intended meaning for "active" is. I don't think the Editor should necessarily follow the active (tab focused) console. I frequently use "Execute in dedicated console", so it always executes in it's own (possibly already open) console, regardless of which console tab has focus. For me, this links the document to an environment, albeit indirectly. It would be much better to link the document to an environment explicitly, whether directly configured, like the per file run configuration, or via project configuration, as we have discussed. The only issue then is how to handle the situation where the document env doesn't match the console env when one "Executes in current console":
|
Yeah; just displaying the env name and included the type, path, etc. in a tooltip this would help, or perhaps not show it for dedicated consoles if we have another mechanism for users explicitly setting this. That raises another question—we didn't consider the case of running files in dedicated consoles; therefore, we should presumably have a way to set the env to run in per-file, otherwise users have to constantly switch their default env to run different files (these suggested changes don't make things worse in that regard, but don't really address that case). However, this could solve two problems at once, this selected environment would both explicitly set the environment to run in (if "Run file in dedicated console/external system terminal" is used), and could also be used to retrieve completions for that file (if the overhead of switching envs in LSP is not so great, IIRC @ccordoba12 said he would look into that).
Currently selected tab; I didn't really consider the other two run config options, sorry.
Coupled with the above approach (which it seems you're thinking of already), I agree this seems the most straightforward and workable solution, and more clearly and explicitly addresses the case of needing different envs for different source files as opposed to the originally proposed approximate heuristic of the currently selected console tab, and without increasing user confusion. The only potential issue is the latency of switching PyLS between envs (or the overhead of running a PyLS per env), but that is the case with any approach that doesn't use a fixed per-project completion env.
I guess this depends on whether you're referring to the dynamic case (running the code from a file) or the static case (providing static completions for it). Assuming we adopt the behavior you mention (do the lookup in the specified environment for the file if explicitly set, otherwise fall back to the default project env) then the currently active console (and thus the setting) doesn't matter, since the operation does not depend on the active console. For the former, if no environment is explicitly set, and only the project-default env differs from that of the currently selected console, then naturally the status quo approach (just run it in the current console anyway) makes the most sense. For cases where an env was explicitly specified for a file, we could automatically switch to and run the code in the last active console with a matching env, which would handle a lot of cases but be far from perfect (what if the user wants to temporarily run the code in a different env? what if no console of that env is open? What if multiple are, and the desired console isn't the last-selected one? etc), so I'd think it would be simplest and least confusing to just follow the current behavior, though perhaps we could add the option for a warning under the "Current console" setting? ( |
I mean that the document env will always be used for completions (and the currently active console doesn't matter) but also be used for execution, in conjunction with the execution configuration (dedicated, external, active).
exactly
I don't think this is good because both the env and the namespace are important. I think for dedicated consoles and external consoles, this is a non-issue. The conflict should only arise when executing in active console.
If they have the document env set and executing in dedicated/external console, they would have to temporarily relax/change one of these settings; there is no way around it. If the document env is set and executing in active console, then they could just run in the active console (with whatever env they setup there).
If dedicated/external console is set, then this is a non issue. Otherwise, just run in active console.
If dedicated/external console is set, then this is a non issue. Otherwise, just run in active console. We can replace "document env" with "effective document env" in all of the above. Summary
Importantly, the above does not really change Spyder's existing behavior, we're simply checking for other environments in front of the default environment in preferences. If the document and project environments are not configured, then the behavior is exactly Spyder's current behavior. So maybe no warnings are required; everything seems pretty logical and what most users would intuitively expect... |
|
But perhaps we're diverting off topic. The issue at hand is how to communicate to the user the completion environment and the console environment... Summary
|
Right, I just wanted to make sure we were talking about the same basic thing
Yeah, as mentioned, neither do I. The questions I posed following it were intended to point out the shortcomings and complexities introduced in what at first seemed to me to be a reasonable heuristic, in support of the following conclusion that retaining the status quo behavior in this case as well (with potential future consideration for a warning or other options to handle it) was likely the best approach. That was what I meant by "so I'd think it would be simplest and least confusing to just follow the current behavior"; sorry for any confusion there.
Right; to be clear, the statements responding to your question related only to the "Current console" case, since that was the case posed.
Exactly.
Agree with all, that was my understanding as well.
Yeah, we can talk with our UX people and less-experienced users to make sure it wouldn't be confusing that they can select an environment but the code is still run in the current console i.e. its just used for static completion. I'd also think it might be useful to have some sort of optional warning or other behavior for cases where the user don't want their code to run in the wrong console, but this use case is probably pretty narrow. We're planning to have a Zoom meeting to discuss this further and would really appreciate having you there for your great input, since you've been the biggest single contributor to making this change happen and provided incredibly valuable feedback, insight and analysis (we meant to invite you to the first one, but there was a mixup on my part); we'll reach out to you shortly with more details on that. |
Yeah, the
I honestly have no idea; its not part of the user-editable name and is set separately. Looking at the code, it looks like it might be some sort of "client ID", but its not clear what it signifies, and I've never seen it anything different then
Yeah, I think this is the simplest approach without inflating the tab name.
I actually suggested a tooltip, but the tab menu would be a great place too as you demonstrate
Right, that's what I'm proposing as well, so we just need to add some UI text (
At first I favored this, but IMO I think its simpler to keep them as they are for now, as described previously:
But we can definitely see what the others think. |
Perhaps
|
Or removing
|
What is the |
It would work as the default way to differentiate consoles using the same env, so you can have
Instead of:
|
|
One issue though is that the numbers are counted sequentially for all consoles, but the position of the number after the "Pylab", etc., implies they are counted separately for each type of console. It also could potentially cause a little confusion as to whether the number implies something about Pylab, Sympy, etc. specifically, Removing the number side-steps the issue, but it could be avoided while keeping the number (which takes up little space and can certainly be useful) by changing it to
|
|
Can we number the consoles only for duplicate console tab text, similar to what most file explorers do when creating new files or folders?
|
|
In that case, if we change the numbering scheme to enumerate duplicates rather than being sequential (which would IMO be a good idea, and would further improve the tab titles), I would suggest some changes:
Thus:
The "different client same kernel" case isn't quite as intuitively clear as before, but given that is rarely used and mostly for advanced users, that's less of a concern than not compromising clarity and conciseness for the other cases (which changing it would require). |
I like this, except possibly
Indeed, I don't see any use case for multiple Spyder consoles connecting to the same kernel. Two consoles connected to the same kernel in Spyder will have exactly the same namespace, etc. What purpose does this serve? It's just a duplicate console 🤷🏼 . Connecting to the same kernel has advantages for different applications, for example if I want to connect a Spyder console and a Jupyter notebook to the same kernel, then both applications have access to the same namespace across applications. |
|
I agree with most of @CAM-Gerlach's last suggestion. The only thing that it's not clear to me is the
It's not super intuitive, but it follows the same convention of What do you think? |
|
Other things to consider are that haven't been discussed before:
|
I guess we could have it be as you suggest, e.g.
Hmm, good point. IMO, in most of those cases we still have some kinda name/identifier for the environment we can use, e.g.
Instead of doing all that which would be long and hard to read, I would just make Pylab, Sympy and Cython sub-menus of their own with a list of environments under that, with the first one being the default. |
I still don't know of any compelling reason to identify kernels. Every console has its own kernel. The only way to have two separate clients with the same kernel is to explicitly connect to an external kernel again. Why would anyone have two consoles (in Spyder) using the same kernel? Just to take up more tab space? Am I missing something here? I think we'd be better off just alerting the user that they already have a client connected to that kernel, rather than duplicating consoles.
Agreed.
I think that would be good. As far as the console tab goes, how about a small icon in the tab that indicates IPython, Pylab, Sympy, or Cython? We just need 4 different icons. Can the tab have hover text? If so, the hover text could show all information: console type, environment type (conda), environment name and/or path (conda, venv, system, etc.), Python version, kernel identifier, ... |
As mentioned in my previous reply, this would mean the submenu is four times as long (which could increase to an unbounded length depending on the number of user environments), and also make the text horizontally longer and more repetitive. If having the special consoles as submenus in a submenu is too many layers of nesting (not an unreasonable position), IMO it would be better overall to just put the submenu for each console type directly in the top-level |
What if users don't venture into using envs and just use the base env for all their computations? In that case, consoles would be named
This is kind of the same scenario as the above one, but for our installers, i.e. consoles would be named
And what if two non-env installations have the same Python version? For instance, two Homebrew and MacPorts Pythons? In that case the Python version is not enough, unless we have What I'd like to highlight with my previous comments is that you (i.e. both @CAM-Gerlach and @mrclary) seem to be optimizing the naming convention for envs. And I think using envs is still an advanced feature that perhaps not many people rely on. So, I propose that we keep using
That's a very good idea. I agree with it. |
I disagree. First, because it'd be a regression in functionality that is quite simple for us to support. And second, because you can have a console filled with results that you don't want to clear, but you could need to run another computation in the same kernel that can have lots of output. In that case, the most natural thing is to connect another client to the same kernel. |
I think having three additional submenus for Pylab, Sympy and Cython inside the |
Thanks @ccordoba12, I had not thought of that. |
|
This may help clarify my thoughts and perhaps be useful to others as well. So take it for what it is worth. Goals:
Information that should be communicated:
Questions:
Comments:
|
Okay, so in that case, we could just go with the
That's exactly what I was proposing. Another alternative instead of Python versions, since most Pythons are either the system Python, Python.org or come with known distributions like MacPorts, Homebrew, Anaconda/Miniconda/Miniforge/Mambaforge, WinPython, deadsnakes etc. (i.e. most of them) where a parent dir in the path we can detect can be matched to a known distribution, we could give the console(s) that name instead. And for the Spyder-managed default env, we don't need to use whatever the actual name is; we can give it a clearer/more user friendly name instead—just If we didn't put the console number in parenthesis, we could put the Python version number in parenthesis, providing nearly complete disambiguation, as it is extremely unlikely users would ever have two separate installs, by the same method (if that's even possible), and with the same Python version. So, my revised suggestion is as follows I'm not even sure we need the So for example: Anaconda For the Python.org Python or custom cases where we can't determine a specific distribution name, environment name or system Python, we could do
I've now modified the convention substially in my latest proposal above to provide a user-friendly name for a variety of env and non-env Python environments.
Well, they really shouldn't be, because as we all know that is how users routinely break things. There has been a concerted push recently to encourage users to always use envs and make it as easy as possible to do so, with e.g. PEP 668 and PEP 704 on the pip side to prevent pip from installing if an environment isn't activated, conda/conda#12245 to do the same for However, even for users not using environments but just specific Python install(s) like you mentioned above, then the revised solution here is equally helpful if not more so, as explained below.
If "Python X.Y" is not sufficiently unique and the user may still not know from which Python the console is being launched from (Homebrew, MacPorts, system Python, Anaconda, etc), then "Console" is even less unique and gives the user even less information on which to go on; my revised proposal aims to specifically address your feedback and tell the user exactly what Python installation they are running right in the Console tab. I'm sure you've seen many users getting confused about where the Python they're using is coming from and where they can install things to it, so this should be a big help in that regard.
Yeah I don't really mind it either way, as my impression is these special console types are not that heavily used by the great majority of users; I mostly suggested flattening it by one level since it seemed like there might be concern with that. If users do raise an issue about it, we can always make the change then.
Well, it's not really a regression if its a minor UI hint indicator for a feature that, as far as I'm aware, few or no users actually use—despite helping probably thousands of Spyder users over the years I don't think I've ever seen any user, in any context, with multiple tabs connected to one console, whereas I have had more than one be confused what the "A" meant. Neither I nor @mrclary had ever used this despite being longtime heavy users of lots of consoles/kernels for half a decade, and I didn't even know what it meant despite writing our current detailed tutorial on connecting to local and remote kernels as well as answering user questions about it. Regarding the use case presented, as someone who heavily relies on many thousands of lines of output history and long scrollback, I wouldn't remotely consider doing this; I'd just increase the number of lines of scrollback in the IPython Console preferences. It is far more "natural" to do that then a user manually figure out what kernel it is and then manually go through the steps to connect to it, with zero indication from the UI, docs or anything else that this is even possible let alone advisable. That being said, as long as we only show |
As suggested above, I suggest we use the Sympy, Cython and Pylab icons to indicate these special types of consoles, and a tooltip to show the other information beyond distribution, environment or file name, Python version and console number.
I would be very surprised if its not, as the editor appears to use the same tabs and has tooltips on them, and its what Isabela suggested above.
The distribution/environment name and Python version should render them fairly unambiguous, but I still propose a sequential number when those two both match, for consistency with the current UI.
As mentioned above, tab text: file name, distribution or environment name, and Python version; type as the respective icon and everything else in a tooltip. |
When I think of my maths undergraduate students, the vast majority (>90%) have never installed a package because Anaconda comes with all that they need. They don't know about environments, they have no need to know about it, and I want us to keep beginners like this in mind. For these people, "Console", "Console 2" etc have proved to be working fine.
This would work even better for beginners, I think, because it's a place for executing Python. However, it seems to contradict what you are proposing later on, when you say:
I can easily imagine beginners confusing an IPython console named "Anaconda" in the tab with the "Anaconda prompt" on Windows. The tension here is that for users that open consoles in different environments, we want to distinguish between the environments and thus mention the environment name. For users that don't know about environments, mentioning the environment name without context is confusing. Maybe there is no good solution, but maybe we can distinguish between these two classes of users. Here are some suggestions:
|
Right, those are two different proposals; the latter was more specifically tailored to address the types of situations @ccordoba12 posed in the quote I was responding to in that one, with a user that has, e.g. Python installed with both Homebrew and Anaconda, which is something users commonly report/open support requests for when they get confused which Python they're running in the IPython Console and why their packages installed in one or the other aren't showing up.
Hmm, that's a good point. We definitely do see users confusing the IPython Console and the Anaconda prompt (and more generally, the Python interpreter vs. their system shell) a fair bit, usually trying to run system commands (typically package installation) in a Python interpreter. Considering this further, I'm now thinking that The examples boil down to basically 2 cases: Anaconda Alternatively, we move the Python version for specific environments to the tooltip (and status bar?) as well, giving us: Anaconda The one downside with either of these is Pythons from different installations that are the same version don't have unique names/get numbered in sequence by default, but that's still a substantial improvement over the entirely generic, redundant and less informative "Console" name. An even better idea for more experienced users would be user-customizable console names. Users could type in their own a template with placeholders for the things @mrclary lists and that we would display in the tooltip (env name, env type, Python version, interpreter path, Console type, etc). But that's definitely more of a nice to have than a requirement.
IMO, there is a fairly straightforward solution, as proposed above—for users who have named and created environments and told Spyder to use them (which would all have to happen for them to show up in the tab in the first place), show the env name (which the user gave the environment) in the console tab. Otherwise, show something more generic, like Python X.Y. That way, users who use environments get the env name, and those who are using the
IMO, these both seem like a lot of complexity for relatively little gain over the more straightforward approach in my current proposals, and I'm unclear on the real gain vs. my most recent proposals of showing the Python version and/or distribution name for consoles not started in an environment.
Yeah, this is what I'm proposing. It's not perfect, but it wouldn't be that inconsistent using the Python version as the default "environment name" and the disadvantage seems very minor to me compared to the others. |
I was about to recommend the same thing. In Preferences -> IPython console -> {Display|Advanced settings} we could have a format template that the user could customize. The default template could be as @CAM-Gerlach has suggested: |
|
So this is how I see the converging consensus so far:
|
|
Thanks @mrclary for summarizing the discussion so far. My comments about it:
Ok, I think this is a good idea to quickly check any console env without clicking on it and then looking at the status bar.
Updating the status bar widget with the console environment is a great idea! Thanks for suggesting that @mrclary. This would make the UX similar to the way the working directory toolbar works, in the sense that if you want to check what cwd (env) the console is in, you need to take a look at the toolbar (status bar). However, I disagree with using icons on it because I'm sure almost all consoles would be IPython ones, so the information conveyed by the icon would be irrelevant most of the time. Furthermore, when switching consoles connected to different envs, we'd need to update the env used by the editor for completions so that users get the completions they'd expect per env. That way, the current env reflected in the status bar would the one used by the console and editor (and also the profiler/code analysis, etc), so using icons tied to the console wouldn't make sense (another advantage of that approach is that we'd be able to remove the Finally, I'd like to maintain that Pylab/Sympy/Cython consoles are simply named
Given that this information would be reflected in the status bar, I see little need to repeat it in the console tab name. So, I propose to leave that feature to be an option in the IPython console preferences, disabled by default. That would also have the advantage of keeping the interface really simple, which would go very well with what @jitseniesen said above:
And @CAM-Gerlach, please refrain from posting another long comment about what I just said if it's going to repeat your points above (which for me drags this kind of discussions to almost a dead end). I understand that you're very passionate about showing env names in console tabs, but I don't think that's the direction we're going to go by default. Instead, I prefer the simpler approach of updating the status bar widget to reflect the current env, name all consoles as If users strongly request that they'd like to see consoles be named as envs, we can reconsider that approach (we know that when our users don't like something, they are very vocal about it). |
I guess I don't really understand the objection to icons. Currently, the console status bar widget does not have an icon, while every other status bar widget does; so it should have an icon to be consistent with the paradigm. Even though most of the time it would be an IPython icon, this information is less irrelevant than "Console" in the console tab. Furthermore, when other console types are used, it conveys the same information in less space than "Cython" or "Pylab" in the console tab.
That is correct, although I don't know if mean to argue in favor of this or against it.
I don't know how this follows from having to update the completions environment.
I did not mention it in my previous comment, but I had the same idea. We could just eliminate the completions status bar widget altogether. |
That's actually not correct. Some widgets have icons and others don't:
This assumes that people have seen the Matplotlib or Cython icons before and can recognize them (I'm not even sure if I'd recognize the Cython icon before googling for it!). And the Sympy icon has a lot of detail, so I doubt it could be displayed correctly in such a small size. So, in this case I'd prefer to be explicit about the special nature of those consoles by "flagging" that in their names.
That's what I'd naturally expect: if I'm working in a console that has Scikit-learn, I'd like to see code completions for it, regardless of what my completions env is. Otherwise, I'd have to always recall that Spyder has a completions env that is different from the console env and which libraries it has. |
Ok, counter proposal to my own proposal so that we can name consoles only as |
|
Saw this trying to use Spyder, want to put in my own experience. When using Thonny, I can go to the menu, pop out a terminal in the current venv, use a GUI in Thonny to search for and install packages, create a new venv, add an existing venv (so it runs the When I opened Spyder, I immediately looked for how to add a virtual environment. It lets me pick a path to an interpreter in the options dialogue, but it isn't clear to me that this will activate the venv (I'm assuming it won't). I looked for a way to get a terminal to add packages with pip, but it wasn't obvious how to do that in the 2 minutes I spent trying. I also couldn't locate the built-in package manager, if any. I checked on Google and found a lot of stuff that said to install Spyder into each Anaconda environment; I'm running Spyder installed from its installer, not conda. I found spyder-env-manager, which said to install it using pip, which again I don't know how to install packages in Spyder's environment (and don't know if that would actually add the plug-in to Spyder). Spyder looks nice, but I went right back to Thonny because I can't figure out how to install numpy. I loaded my Pi Pico with a custom-compiled version of Micropython with ulab; doing that was more obvious than figuring out how to run pip in Spyder's Python environment. Not being able to install or select a venv (putting aside being stuck on Python 3.8, which is its own problem) and manage packages (by getting a terminal open in the venv, or by having a GUI to manage packages) is the only thing blocking me from using Spyder right now. From my perspective, the lack of a venv manager and some obvious way to install packages (even getting a terminal open is either non-obvious or not in Spyder—there is a plugin for this, the only thing online about installing Spyder plugins has to do with already being in a terminal for the Python environment Spider's running in, this is a causality loop that may very well destroy the entire universe) is the biggest barrier to accessibility. Spyder becomes "you can use this IDE only with the special environment it comes with and only with the default Python modules" even for moderately experienced developers, which is completely useless (hence being a barrier to accessibility). As far as I can tell, Spyder only really works for conda users. |
To make it easier to switch what a new console defaults to and to change the environment for an existing console, we can add a menu from the lower status bar similar to the language server to its left.
Here is my proposal:
The default option will always be at the top, separated from the other options, and has the (Default) label. All other options should be listed below alphabetically with a check (Material Icons check) to the left of whichever option is being used by the currently selected console.
To change the default, hovering over that option opens the secondary menu. It follows the same pattern of alphabetic listing and check for currently selected default/
The text was updated successfully, but these errors were encountered: