Spyder with multiple python envs

[gar...@gmail.com]

I'm reposting this from winpython group on request from Jed. Surely this is more appropriate for this kind of query.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hi all,
i've been working for large shops, mainly using Java with eclipse, so choosing pydev for python development was a natural consequence.

I currently work on projects using python 2.7 and 3.3 both 32 and 64 bit (i have installed your wonderful winpython releases), i'm using local sites and a bunch of chained virtualenv's (using virtualenv_path_extensions.pth to build inherit hierarchies) and i can easily maintain all this mess from a single pydev cockpit using different interpreter definitions and assigning the right interpreter to each project.

But as you know eclipse is sometimes a sort of overkill when you only need to develop and maintain python projects and i would prefer a pure python implementation for the ide. I'm examining alternatives and spyder looked very promising until i stumbled on issue 1402 and  issue 1415.

In the former you say that you won't develop develop further the virtualenv support and that you won't support projects using different python environments and the only way to support different environments is to install spyder in each of them. The latter seems to keep still some doors opened.

Given this premise i'm asking if what you affirm in the first issue is the definitive roadmap for spyder development, because in this case i think for me it is a dead end road (sadly, i have to say, because apart from this it gives me a very good feeling and it has some features i really do like).

I'ts true that eclipse is sometime heavy but, if i didn't misunderstand your words, in my case i'd have to substitute a single point of control with 10, 12 different spyder installations, to configure, maintain, update... and this is really a no go condition for me.

Best regards,
Gabriele

[Jed Ludlow]

On Tuesday, June 25, 2013 2:03:24 AM UTC-6, gar...@gmail.com wrote:

I'm reposting this from winpython group on request from Jed. Surely this is more appropriate for this kind of query.
--------------------------------------------------------------------------------------------------------------------------------------------------------------------
Hi all,
i've been working for large shops, mainly using Java with eclipse, so choosing pydev for python development was a natural consequence.

I currently work on projects using python 2.7 and 3.3 both 32 and 64 bit (i have installed your wonderful winpython releases), i'm using local sites and a bunch of chained virtualenv's (using virtualenv_path_extensions.pth to build inherit hierarchies) and i can easily maintain all this mess from a single pydev cockpit using different interpreter definitions and assigning the right interpreter to each project.

To be honest, PyDev or Python Tools for Visual Studio are perfectly suited to this type of development, and we are not really aiming to match their level of configurability. In fact, one of our primary goals is to avoid the necessity of configuring Python environments before being able to run anything. For the large majority of scientific Python use cases, having a large number of virtual environments for more heavyweight development isn't that common. Instead, Spyder's primary focus is to provide a flexible environment for scientific exploration with some additional tools to help turn those explorations into something that looks more like a piece of software.

But as you know eclipse is sometimes a sort of overkill when you only need to develop and maintain python projects and i would prefer a pure python implementation for the ide. I'm examining alternatives and spyder looked very promising until i stumbled on issue 1402 and  issue 1415.

In the former you say that you won't develop develop further the virtualenv support and that you won't support projects using different python environments and the only way to support different environments is to install spyder in each of them. The latter seems to keep still some doors opened.

To be more clear, the resolution reached in issue 1402 is that all of Spyder's introspection features like pyflakes, rope, and pep8 will run in the environment in which Spyder itself is running. This frees us from the overhead of having to run all of these actions in external processes. It also means that there is not requirement for heavyweight projects to pre-specify a target environment.

Now, that said, today Spyder still allows you to point to a Python executable into which all of Spyder's consoles will launch. By default on the first Spyder launch this gets set to the the environment in which Spyder is running. The gist of issue 1415 is that this setting is global. So if you did subsequently install Spyder into multiple environments this setting will still point back to the interpreter where Spyder was first run. Issue 1415 was to highlight this issue and the more general issue of dealing with a global user configuration across multiple environments.

 

Given this premise i'm asking if what you affirm in the first issue is the definitive roadmap for spyder development, because in this case i think for me it is a dead end road (sadly, i have to say, because apart from this it gives me a very good feeling and it has some features i really do like).

I'ts true that eclipse is sometime heavy but, if i didn't misunderstand your words, in my case i'd have to substitute a single point of control with 10, 12 different spyder installations, to configure, maintain, update... and this is really a no go condition for me.

Would it be acceptable if we were to remove the global python interpreter setting that exists today and allow you to configure on a per-script or per project basis a Python interpreter to be used for "Run" requests? In that case, you'd still install Spyder into, say, your base 2.7 and 3.3 environments, and these environments would be used for code completion, pyflakes, and pep3. But you would then be able to point any particular script to be executed in one of your other virtualenvs?

Jed

[David Verelst]

I think having an additional option to specify the python interpreter in the run settings would be a great feature. I do some work, but not all, in a separate virtual environment, and therefore it would be very practical to chose a Python interpreter on a per script basis. However, as mentioned before, users could be confused since the Spyder's main process (and corresponding code analysis and introspection features) might run in another environment that does not include certain modules: code completion might work in the console but not in the editor. I think from a usability perspective (or what would you call such a thing?) this is very bad. On the other hand, it really is a great feature to have when working with different environments. Maybe as long as the user is made aware of this shortcoming (although a novice user shouldn't be bothered with this at all) it is worth it.

David

--
You received this message because you are subscribed to the Google Groups "spyder" group.
To unsubscribe from this group and stop receiving emails from it, send an email to spyderlib+...@googlegroups.com.
To post to this group, send email to spyd...@googlegroups.com.
Visit this group at http://groups.google.com/group/spyderlib.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Carlos Córdoba]

The idea is to offer this option inside an advanced section of our "Run Settings" dialog, that would be collapsed by default, so that people doesn't mess around with it.

El 08/07/13 03:52, David Verelst escribió:

[gar...@gmail.com]

On Friday, July 5, 2013 6:29:36 PM UTC+2, Jed Ludlow wrote:

Would it be acceptable if we were to remove the global python interpreter setting that exists today and allow you to configure on a per-script or per project basis a Python interpreter to be used for "Run" requests? In that case, you'd still install Spyder into, say, your base 2.7 and 3.3 environments, and these environments would be used for code completion, pyflakes, and pep3. But you would then be able to point any particular script to be executed in one of your other virtualenvs?

Well, this is the first step in the right direction ;)
I mean that the change you are planning is removing a severe restriction and for simple scripts this could be enough, but for the kind of work i'm doing i need that code completion, analysis, etc. include the same virtualenv modules as the runtime otherwise coding would became a pain.
In other words, i'm not a python internal guru and i never thought of the intricacies this may cause while writing an ide, but i couldn't think of anything different than configuring an "interpreter", a la pydev, to have the coding and run time envs of a project behaving coherently.
Thanks anyway for the effort.

Gabriele