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ó:
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]
<mailto:[email protected]>> wrote:
On Tuesday, June 25, 2013 2:03:24 AM UTC-6, [email protected]
<mailto:[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]
<mailto:spyderlib%[email protected]>.
To post to this group, send email to [email protected]
<mailto:[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.
--
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.
