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 On 5 July 2013 18:29, Jed Ludlow <[email protected]> wrote: > On Tuesday, June 25, 2013 2:03:24 AM UTC-6, [email protected] 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<http://code.google.com/p/spyderlib/issues/detail?id=1402>and issue >> 1415 <http://code.google.com/p/spyderlib/issues/detail?id=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 > > -- > 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 [email protected]. > To post to this group, send email to [email protected]. > Visit this group at http://groups.google.com/group/spyderlib. > For more options, visit https://groups.google.com/groups/opt_out. > > > -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at http://groups.google.com/group/spyderlib. For more options, visit https://groups.google.com/groups/opt_out.
