pydev-code — For registered developers

[Pydev-code] configuring Python Interpreter for more unusual setups

[Jonah G. <jo...@ki...>]

I have a follow-up questions related to configuring the Python
Interpreter for what may be considered more "unusual" setups.

The state of play today:
1) When creating the interpreter info, the Python reported
sys.executable is used as the exeOrJar value. (i.e. <executable> in
interpreterInfo.py output). This means if you select /usr/bin/python
in the GUI, but that actually a link to /usr/bin/python2.7, the
exeOrJar added is /usr/bin/python2.7.
2) The default selected Python Path is based on whether the folder is
in sys.prefix (i.e. <lib path="ins">/<lib path="out"> in
interpreterInfo.py output)
3) Jython interpreter must be a jar file[1]

Both of these issues affect configuring PyDev for an interpreter that
has a custom launch script around it. Two examples are jython on
Ubuntu and cctbx.python (http://cci.lbl.gov/cctbx_build/). The wrapper
scripts set up the interpreter properly (e.g. adding -Dpython.home or
setting LD_LIBRARY_PATH). However, because PyDev uses the advertised
sys.executable, these interpreters don't work after creation.

What I would like to propose is:
1) that the sys.executable is no longer used, and instead PyDev uses
the path supplied by the user. [2]
2) the default paths included are all the paths in sys.path (apart
from the ones PyDev is inserting, e.g. org.python.pydev/pysrc)
3) Allow Jython to be configured as a wrapper script (i.e. launch as
exe) (this is actually an orthogonal change, but somewhat related. I
see this has been an issue before:
http://stackoverflow.com/questions/10671446/error-configuring-jython-2-5-1-on-eclipse-3-7-2-on-ubuntu-12-04
[3])

Frankly, I fear that there are many unknown (to me) issues with making
this kind of change.

If this sounds broadly acceptable, I will formulate this as an actual
pull request for proper review. However, if this is unlikely to be
accepted in any way, I would much appreciate the heads up so that I
can start looking to permanently solve my interpreter info issues
another way.

[1] /usr/bin/jython on Ubuntu can be configured as a Python
interpreter but not a Jython interpreter. However I don't know how
much real mileage you can really get on that.
[2] As mitigation, if this seems too much of a change, is to add a
checkbox on the New... or alternatively an addition step in the wizard
that lets the user select sys.executable value or user entered value
[3] I don't know if there are other places in PyDev that rely on
Jython.jar being run with the same java as is known to Eclipse. For
example, on Ubuntu it is fairly easy to have /usr/bin/jython use a
different java than Eclipse is run with.

Thanks for taking time to consider this,
Jonah


On 1 August 2013 21:59, Jonah Graham <jo...@ki...> wrote:
> Hi Andrew and Fabio,
>
> I would like to add my two-cents on this topic. Echoing what Fabio
> said, I think that PyDev should not include a pre-configured Python
> (or other environment), however if redhat is providing pydev packages
> ready to use, it should include pydev configured for the python
> packages. (Same applies to other distributions, where possible.)
>
> I think this should be an external plug-in to pydev, using the
> extensions available.
>
> One option is to fully configure the interpreter. Dawn has a similar
> use case where jython is packaged to allow scripting of the Dawn suite
> of tools. At Dawn we use:
> https://github.com/DawnScience/scisoft-ui/blob/master/uk.ac.diamond.scisoft/src/uk/ac/diamond/scisoft/JythonCreator.java
> to create a Jython Interpreter info automatically. I assume that
> froglogic's squish does something similar as it includes an Eclipse
> based IDE using PyDev and a  Python build in its install tree and the
> Python is all configured in PyDev.
>
> Another option is to use/extend my recently contributed changes to
> PyDev to allow the "Auto" button to be extended. For example, the
> default implementation of Auto just searches for python, an improved
> version could look for python2 or python3.2 or whatever else is
> installed by the package manager. In this situation, a new plug-in
> that uses package info can contribute to PyDev's Auto by using
> org.python.pydev.pydev_interpreter_provider to provide a list of all
> installed Python's known. This new extension point has the option to
> run an install process too when selected, i.e. it could run yum or
> whatever to install python.
>
> I originally implemented this new feature to make it easier for
> scientists (who may have limited previous knowledge of
> installing/configuring Python) to get started with Dawn. It gives the
> option during Auto to install EPD Free's distribution of Python
> https://www.enthought.com/products/epd/free/. The advantage of EPD is
> that it is already preconfigured with all the packages the scientists
> are likely to need.
>
> See https://github.com/fabioz/Pydev/pull/38 for the pull request that
> added the feature.
>
> One final thought. I am about to do some work to make it easier to use
> cctbx python with PyDev (for Dawn again). cctbx has some extra
> settings that need to be set-up correctly. I haven't investigated this
> much yet, but I may extend the above mentioned extension point to
> allow further configuring of the interpreter info after creation. (The
> current extension point stops at providing an IInterpreterProvider
> which provides install option and path/name of installed python).
> There has also been some discussion of making Sage work with Dawn and
> PyDev, but I don't know how much demand there is for that yet.
>
> BTW Dawn's website in case you haven't come across it:
> http://www.dawnsci.org/ Much of the work I am currently doing for
> PyDev is funded by Diamond Light Source http://diamond.ac.uk/ to work
> on improving Dawn.
>
> Jonah
>
>
> On 1 August 2013 19:20, Fabio Zadrozny <fa...@gm...> wrote:
>> Hi Andrew,
>>
>> Actually, it *should* be much better now than at that bug report:
>>
>> Right now, when PyDev is activated (i.e.: a Python editor is opened or
>> something that requires the interpreter), PyDev will already try to
>> auto-configure an interpreter, searching on different locations depending on
>> your platform.
>>
>> After doing that, it'll still ask the user to confirm if that's correct,
>> which I think is something good to have so that he can at least check we got
>> the correct interpreter.
>>
>> This happens at
>> org.python.pydev.ui.interpreters.AbstractInterpreterManager.ConfigureInterpreterJob
>> (you can test on a brand new workspace opening a .py file).
>>
>> So, I think the issue is mostly dealt with...
>>
>> What can still be done to improve the situation is that when the new project
>> wizard (which you're familiar with) is opened, if the user still has no
>> interpreter configured, we'll try to configure it automatically there too
>> (because right now, if he goes there without a configured interpreter, he
>> has to manually click the link to choose the interpreter and press
>> 'auto-config': this could be done for him as we know he'll have to click
>> that link before proceeding because he has no interpreter configured -- you
>> can check ConfigureInterpreterJob as a reference for how to do that).
>>
>> Cheers,
>>
>> Fabio
>>
>>
>> On Thu, Aug 1, 2013 at 2:38 PM, Andrew Ferrazzutti <afe...@re...>
>> wrote:
>>>
>>> Hi Fabio,
>>>
>>> Alex recently assigned me to the bug where PyDev doesn't come a
>>> pre-configured Python environment. Considering this bug was reported six
>>> years ago, I'm assuming there's some reason why it hasn't been addressed. Is
>>> there a certain way you wanted this to be fixed? Alex suggested using an
>>> extension point to automatically search for /usr/bin/python or somewhere
>>> similar for a usable binary. If there's some other method you'd rather use
>>> I'm all ears.
>>>
>>> Andrew
>>
>>
>>
>> ------------------------------------------------------------------------------
>> Get your SQL database under version control now!
>> Version control is standard for application code, but databases havent
>> caught up. So what steps can you take to put your SQL databases under
>> version control? Why should you start doing it? Read more to find out.
>> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
>> _______________________________________________
>> pydev-code mailing list
>> pyd...@li...
>> https://lists.sourceforge.net/lists/listinfo/pydev-code
>>

Re: [Pydev-code] Add 'global functions' to PyDev analyzer

[Jonah G. <jo...@ki...>]

Hi,

I need to solve a similar problem. I have some scripts that are user
editable, but are run by an execfile with some other magic wrapped
around it. In that magic some new globals are added, which seem in a
similar way to how web2py is described in
http://sourceforge.net/p/pydev/feature-requests/534/

What I would like to do is add a new extension point to extend the
behaviour of CompiledModule:setTokens() and have it essentially add
new values to "array" within this if statement?

            //as we will use it for code completion on sources that
map to modules, the __file__ should also
            //be added...
            if (array.size() > 0 && (name.equals("__builtin__") ||
name.equals("builtins"))) {
                array.add(new CompiledToken("__file__", "", "", name,
IToken.TYPE_BUILTIN));
                array.add(new CompiledToken("__name__", "", "", name,
IToken.TYPE_BUILTIN));
                array.add(new CompiledToken("__builtins__", "", "",
name, IToken.TYPE_BUILTIN));
                array.add(new CompiledToken("__dict__", "", "", name,
IToken.TYPE_BUILTIN));
// extension point data insertion would be here[1]
            }

Does that sound like a correct solution? Does that seem generally
useful? If so I can put an initial pull request together for review.

[1] Should the extension point users return AbstractToken, or is there
a subset of that API that should be exposed (e.g. just name). My
preference would be AbstractToken, to allow full range of options for
extension point user.

Jonah


On 23 July 2013 12:39, Fabio Zadrozny <fa...@es...> wrote:
> On Tue, Jul 23, 2013 at 4:46 AM, Andreas Pakulat <an...@fr...>
> wrote:
>>
>> Hi Fabio,
>>
>> thanks for the hint about the pycompletionserver.py. Currently we
>> already have a change or two to PyDev and roll our own but we would
>> rather use the official version.
>>
>> Unfortunately our interpreter is embedded into a commandline tool that
>> does not support being used like a normal python interpreter. So thats
>> why  choosing it as an interpreter is not suitable at the moment. What
>> it does is basically load the main script file (i.e. parse it but does
>> not run it immediately), then add a few modules to the python
>> interpreter via C API, import those modules into the global namespace of
>> the main script file and also import several functions into the global
>> namespace. This was done as a convenience for the users but now clearly
>> bites back at us when trying to teach PyDev about these specialties.
>
>
> Ok, so, it's not really a custom interpreter, just a different main... Not
> sure if that's the best approach (I'd probably go toward a more common
> approach of having a different main entry which then would run the script
> after configuring the environment, such as most web frameworks do or maybe a
> custom sitecustomize).
>
> Still, if you bundle it as an executable, it shouldn't be all that hard to
> make it look like a real python interpreter (i.e.: one that could really be
> used as an interpreter -- that way you wouldn't need to change PyDev at all
> and everything should just work). This is probably the preferred approach.
>
> Now, if that's difficult for you, the pycompletionserver.py/importsTipper.py
> adjustment probably requires less fiddling to integrate.
>
> Regarding a better approach within PyDev itself, please create a feature
> request for that in https://sw-brainwy.rhcloud.com/tracker/PyDev/ (this is
> also a request web2py users have -- for which there's a discussed workaround
> detailed at the old tracker:
> http://sourceforge.net/p/pydev/feature-requests/534/).
>
>>
>>
>> Its of course also possible to import those registered modules in the
>> script file or in one that is being imported into the main script.
>>
>> What I ended up doing now which seems to work with 2 caveats (see
>> further down) is that I'm using the extension points
>> pydev_interpreter_new_custom_entries, pydev_modules_observer and the
>> completion extension point. The first one registers the names of the
>> modules we add via the C API as 'builtins', the second one adds tokens
>> to the __builtin__ module for those modules and the functions we import
>> into the global namespace. It also populates our modules with their
>> functions when the PyDev code needs them (a script importing our squish
>> module for example). All this seems to avoid errors being flagged for
>> our Squish API, but does not yet provide the modules and functions for
>> completion. Hence using the completion extension point to support that.
>>
>> The two minor issues with this are:
>>
>> 1. For the builtins registration using the
>> pydev_interpreter_new_custom_entries extension point the users need to
>> remove and re-add the interpreter so that PyDev fetches the builtins
>> again.
>>
>> Maybe there's a way to do the above programatically upon startup of a
>> plugin?
>>
>> 2. When using 'import squish' in a script now a warning is flagged
>> about this shadowing a builtin module which is correct from what PyDev
>> knows but not really happening in the actual interpreter that executes
>> the tests.
>>
>> The second point is not much of a problem as its just a warning and
>> hence does not jump out at the user as much as an error (in particular
>> an error in script code that Squish just generated).
>>
>> Andreas
>>
>>
>> On 2013-07-22 22:39, Fabio Zadrozny wrote:
>> > Hi Andreas,
>> >
>> > Actually, if you really have a custom interpreter and this is added
>> > in its startup, it's strange that it doesn't work already (PyDev
>> > always spawns a shell for the completion and upon startup it'll load
>> > the __builtin__ -- or builtins -- module and do a dir() in it).
>> >
>> > So, if it's custom interpreter, it's mostly a matter of filling the
>> > __builtins__ at the startup... If that's not the case, you could
>> > change PyDev to add some custom code at the module scope at
>> > /org.python.pydev/pysrc/pycompletionserver.py (but you'll have to
>> > maintain your own fork if you choose this path).
>> >
>> > Cheers,
>> >
>> > Fabio
>> >
>> > On Fri, Jul 19, 2013 at 12:15 PM, Andreas Pakulat
>> > <an...@fr...> wrote:
>> >
>> >> Hi,
>> >>
>> >> I'm currently working on improving our usage of PyDev, in particular
>> >> starting to let PyDev not only syntax highlight but also analyze the
>> >> code our users write. Unfortunately this has one drawback, we use a
>> >> custom interpreter and add several global functions to it (this is
>> >> done
>> >> by having a module for these functions and then importing everything
>> >> from this module by default into the global namespace).
>> >>
>> >> I know about the setting for the PyDev analyzer to not show errors
>> >> on
>> >> certain undefined functions/variables, but the number of functions
>> >> makes
>> >> this single lineedit/preference pretty cumbersome to extend.
>> >>
>> >> I'm wondering wether there's a different way (via code maybe?) to
>> >> teach
>> >> PyDev about a list of functions it should consider to be
>> >> 'predefined',
>> >> similar to the builtin modules?
>> >>
>> >> I'm currently using PyDev 2.6, but could upgrade to 2.7.5 if that
>> >> makes
>> >> it easier to achieve what I want.
>> >>
>> >> Andreas
>> >>
>> >> --
>> >> Andreas Pakulat sq...@fr...
>> >> froglogic GmbH - Automated UI and Web Testing
>> >>
>> >>
>> >>
>> >> ------------------------------------------------------------------------------
>> >> See everything from the browser to the database with AppDynamics
>> >> Get end-to-end visibility with application monitoring from
>> >> AppDynamics
>> >> Isolate bottlenecks and diagnose root cause in seconds.
>> >> Start your free trial of AppDynamics Pro today!
>> >>
>> >>
>> >> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >> [1]
>> >> _______________________________________________
>> >> pydev-code mailing list
>> >> pyd...@li...
>> >> https://lists.sourceforge.net/lists/listinfo/pydev-code [2]
>> >
>> >
>> >
>> > Links:
>> > ------
>> > [1]
>> >
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&amp;iu=/4140/ostg.clktrk
>> > [2] https://lists.sourceforge.net/lists/listinfo/pydev-code
>> >
>> >
>> >
>> > ------------------------------------------------------------------------------
>> > See everything from the browser to the database with AppDynamics
>> > Get end-to-end visibility with application monitoring from
>> > AppDynamics
>> > Isolate bottlenecks and diagnose root cause in seconds.
>> > Start your free trial of AppDynamics Pro today!
>> >
>> >
>> > http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> >
>> > _______________________________________________
>> > pydev-code mailing list
>> > pyd...@li...
>> > https://lists.sourceforge.net/lists/listinfo/pydev-code
>>
>> --
>> Andreas Pakulat sq...@fr...
>> froglogic GmbH - Automated UI and Web Testing
>>
>>
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>>
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>> _______________________________________________
>> pydev-code mailing list
>> pyd...@li...
>> https://lists.sourceforge.net/lists/listinfo/pydev-code
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>

Re: [Pydev-code] Java 7 and Apache Commons

[Fabio Z. <fa...@es...>]

Hi Jonah,

I'll do the following: I'll create a blog entry to ask people what they
think about... personally, I think going forward is nice, but I'd like to
check with the current user base if that's an issue... (at a time I know
Mac OS users had problems updating to more recent versions of Java, and
Eclipse 3.2 was the version used by Aptana Studio 2, but I don't think it
has to be supported anymore).

So, I'll ask users to be able to give you feedback :)

Cheers,

Fabio




On Wed, Aug 7, 2013 at 11:48 AM, Jonah Graham <jo...@ki...>wrote:

> Hello,
>
> I know that PyDev officially supports Eclipse 3.2+[1]/Java 6+ (or
> 5?)[2], however I would like to use some features of Java 7 (e.g.
> java.nio stuff). In addition I would love to be able to use various
> apache commons stuff (e.g. StringUtils[3]).
>
> What are the issues/(other?) with supporting older versions of
> Eclipse/Java/etc?
>
> Thoughts/comments?
> Thanks,
> Jonah
>
> [1] There is a little bit of code with correct try/catch in
> PydevPlugin for supporting Eclipse 4+ if it is available.
> [2] On http://pydev.org/download.html it states Jave 6+ (Java 7
> recommended), but on http://pydev.org/developers.html for developers
> the request is still Java 5 API?
> [3] If PyDev did become dependent on apache commons, then I could go
> and remove the (then) redundant code in PyDev's StringUtils?
>
>
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite!
> It's a free troubleshooting tool designed for production.
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>

[Pydev-code] Java 7 and Apache Commons

[Jonah G. <jo...@ki...>]

Hello,

I know that PyDev officially supports Eclipse 3.2+[1]/Java 6+ (or
5?)[2], however I would like to use some features of Java 7 (e.g.
java.nio stuff). In addition I would love to be able to use various
apache commons stuff (e.g. StringUtils[3]).

What are the issues/(other?) with supporting older versions of Eclipse/Java/etc?

Thoughts/comments?
Thanks,
Jonah

[1] There is a little bit of code with correct try/catch in
PydevPlugin for supporting Eclipse 4+ if it is available.
[2] On http://pydev.org/download.html it states Jave 6+ (Java 7
recommended), but on http://pydev.org/developers.html for developers
the request is still Java 5 API?
[3] If PyDev did become dependent on apache commons, then I could go
and remove the (then) redundant code in PyDev's StringUtils?

Re: [Pydev-code] Bug 242011 - pydev plugin should have a pre-configured python environment

[Jonah G. <jo...@ki...>]

Hi Andrew and Fabio,

I would like to add my two-cents on this topic. Echoing what Fabio
said, I think that PyDev should not include a pre-configured Python
(or other environment), however if redhat is providing pydev packages
ready to use, it should include pydev configured for the python
packages. (Same applies to other distributions, where possible.)

I think this should be an external plug-in to pydev, using the
extensions available.

One option is to fully configure the interpreter. Dawn has a similar
use case where jython is packaged to allow scripting of the Dawn suite
of tools. At Dawn we use:
https://github.com/DawnScience/scisoft-ui/blob/master/uk.ac.diamond.scisoft/src/uk/ac/diamond/scisoft/JythonCreator.java
to create a Jython Interpreter info automatically. I assume that
froglogic's squish does something similar as it includes an Eclipse
based IDE using PyDev and a  Python build in its install tree and the
Python is all configured in PyDev.

Another option is to use/extend my recently contributed changes to
PyDev to allow the "Auto" button to be extended. For example, the
default implementation of Auto just searches for python, an improved
version could look for python2 or python3.2 or whatever else is
installed by the package manager. In this situation, a new plug-in
that uses package info can contribute to PyDev's Auto by using
org.python.pydev.pydev_interpreter_provider to provide a list of all
installed Python's known. This new extension point has the option to
run an install process too when selected, i.e. it could run yum or
whatever to install python.

I originally implemented this new feature to make it easier for
scientists (who may have limited previous knowledge of
installing/configuring Python) to get started with Dawn. It gives the
option during Auto to install EPD Free's distribution of Python
https://www.enthought.com/products/epd/free/. The advantage of EPD is
that it is already preconfigured with all the packages the scientists
are likely to need.

See https://github.com/fabioz/Pydev/pull/38 for the pull request that
added the feature.

One final thought. I am about to do some work to make it easier to use
cctbx python with PyDev (for Dawn again). cctbx has some extra
settings that need to be set-up correctly. I haven't investigated this
much yet, but I may extend the above mentioned extension point to
allow further configuring of the interpreter info after creation. (The
current extension point stops at providing an IInterpreterProvider
which provides install option and path/name of installed python).
There has also been some discussion of making Sage work with Dawn and
PyDev, but I don't know how much demand there is for that yet.

BTW Dawn's website in case you haven't come across it:
http://www.dawnsci.org/ Much of the work I am currently doing for
PyDev is funded by Diamond Light Source http://diamond.ac.uk/ to work
on improving Dawn.

Jonah


On 1 August 2013 19:20, Fabio Zadrozny <fa...@gm...> wrote:
> Hi Andrew,
>
> Actually, it *should* be much better now than at that bug report:
>
> Right now, when PyDev is activated (i.e.: a Python editor is opened or
> something that requires the interpreter), PyDev will already try to
> auto-configure an interpreter, searching on different locations depending on
> your platform.
>
> After doing that, it'll still ask the user to confirm if that's correct,
> which I think is something good to have so that he can at least check we got
> the correct interpreter.
>
> This happens at
> org.python.pydev.ui.interpreters.AbstractInterpreterManager.ConfigureInterpreterJob
> (you can test on a brand new workspace opening a .py file).
>
> So, I think the issue is mostly dealt with...
>
> What can still be done to improve the situation is that when the new project
> wizard (which you're familiar with) is opened, if the user still has no
> interpreter configured, we'll try to configure it automatically there too
> (because right now, if he goes there without a configured interpreter, he
> has to manually click the link to choose the interpreter and press
> 'auto-config': this could be done for him as we know he'll have to click
> that link before proceeding because he has no interpreter configured -- you
> can check ConfigureInterpreterJob as a reference for how to do that).
>
> Cheers,
>
> Fabio
>
>
> On Thu, Aug 1, 2013 at 2:38 PM, Andrew Ferrazzutti <afe...@re...>
> wrote:
>>
>> Hi Fabio,
>>
>> Alex recently assigned me to the bug where PyDev doesn't come a
>> pre-configured Python environment. Considering this bug was reported six
>> years ago, I'm assuming there's some reason why it hasn't been addressed. Is
>> there a certain way you wanted this to be fixed? Alex suggested using an
>> extension point to automatically search for /usr/bin/python or somewhere
>> similar for a usable binary. If there's some other method you'd rather use
>> I'm all ears.
>>
>> Andrew
>
>
>
> ------------------------------------------------------------------------------
> Get your SQL database under version control now!
> Version control is standard for application code, but databases havent
> caught up. So what steps can you take to put your SQL databases under
> version control? Why should you start doing it? Read more to find out.
> http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>

Re: [Pydev-code] Bug 242011 - pydev plugin should have a pre-configured python environment

[Fabio Z. <fa...@gm...>]

Hi Andrew,

Actually, it *should* be much better now than at that bug report:

Right now, when PyDev is activated (i.e.: a Python editor is opened or
something that requires the interpreter), PyDev will already try to
auto-configure an interpreter, searching on different locations depending
on your platform.

After doing that, it'll still ask the user to confirm if that's correct,
which I think is something good to have so that he can at least check we
got the correct interpreter.

This happens
at org.python.pydev.ui.interpreters.AbstractInterpreterManager.ConfigureInterpreterJob
(you can test on a brand new workspace opening a .py file).

So, I think the issue is mostly dealt with...

What can still be done to improve the situation is that when the new
project wizard (which you're familiar with) is opened, if the user still
has no interpreter configured, we'll try to configure it automatically
there too (because right now, if he goes there without a configured
interpreter, he has to manually click the link to choose the interpreter
and press 'auto-config': this could be done for him as we know he'll have
to click that link before proceeding because he has no interpreter
configured -- you can check ConfigureInterpreterJob as a reference for how
to do that).

Cheers,

Fabio


On Thu, Aug 1, 2013 at 2:38 PM, Andrew Ferrazzutti <afe...@re...>wrote:

> Hi Fabio,
>
> Alex recently assigned me to the bug where PyDev doesn't come a
> pre-configured Python environment. Considering this bug was reported six
> years ago, I'm assuming there's some reason why it hasn't been addressed.
> Is there a certain way you wanted this to be fixed? Alex suggested using an
> extension point to automatically search for /usr/bin/python or somewhere
> similar for a usable binary. If there's some other method you'd rather use
> I'm all ears.
>
> Andrew
>

[Pydev-code] Bug 242011 - pydev plugin should have a pre-configured python environment

[Andrew F. <afe...@re...>]

Hi Fabio,

Alex recently assigned me to the bug where PyDev doesn't come a pre-configured Python environment. Considering this bug was reported six years ago, I'm assuming there's some reason why it hasn't been addressed. Is there a certain way you wanted this to be fixed? Alex suggested using an extension point to automatically search for /usr/bin/python or somewhere similar for a usable binary. If there's some other method you'd rather use I'm all ears.

Andrew

Re: [Pydev-code] View Database Diagram

[Fabio Z. <fa...@es...>]

Hi Sayth,

Right now you have to do that through the PyDev package explorer (there's
no special support regarding that).

Please note that this is not the best place to ask this: the pydev-code
list is related to code and not really user support (use stackoverflow
adding a 'pydev' tag for that).

Best Regards,

Fabio


On Wed, Jul 24, 2013 at 9:15 PM, Sayth Renshaw <fle...@gm...>wrote:

> What is the best way to graphically view your django database models in
> pydev/ eclipse?
>
> Sayth
>
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>
>

[Pydev-code] PyDev 2.8.0 Released

[Fabio Z. <fa...@gm...>]

Hi All,

PyDev 2.8.0 has been released

Details on PyDev: http://pydev.org
Details on its development: http://pydev.blogspot.com

Release Highlights:
-------------------------------

* Type Inference now works with docstrings (Sphinx or Epydoc). See:
http://pydev.org/manual_adv_type_hints.html

* Fixed debugger to work on Google App Engine

* Patch by Edward Catmur

    * Interactive console supports running with the Qt and Gtk event loops

* Patches by Andrew Ferrazzutti

    * Multiple main modules/packages may be selected in the unittest run
configuration

    * Properly handling unittest errors caused by setUpClass/setUpModule
exceptions

    * It's possible to select the Working Set configuration in the New
PyDev Project wizard

* Patches by Christoph Zwerschke

    * It's possible to specify PyLint settings per project by passing
--rcfile=.pylintrc (it's now run relative to the project directory)

    * PyLint now accepts an executable so that it does not have to rely on
the configured interpreter.

* Fixed OutOfMemoryError when large file was found in the workspace.

* Editor startup is now faster due to improvements in Jython scripts.

* Improved the way that the interpreter location is shown on the pydev
package explorer.

* PyDev Package Explorer icon no longer missing when top level elements is
set to Working Sets

* Other minor bugfixes

Note: PyDev is now signed with a new (self-signed) certificate (see
http://pydev.org/manual_101_install.html for the new certificate) .



What is PyDev?
---------------------------

PyDev is a plugin that enables users to use Eclipse for Python, Jython and
IronPython development -- making Eclipse a first class Python IDE -- It
comes with many goodies such as code completion, syntax highlighting,
syntax analysis, refactor, debug and many others.


Cheers,

-- 
Fabio Zadrozny
------------------------------------------------------
Software Developer

PyDev - Python Development Environment for Eclipse
http://pydev.org
http://pydev.blogspot.com

[Pydev-code] View Database Diagram

[Sayth R. <fle...@gm...>]

What is the best way to graphically view your django database models in
pydev/ eclipse?

Sayth

Re: [Pydev-code] Add 'global functions' to PyDev analyzer

[Fabio Z. <fa...@es...>]

On Tue, Jul 23, 2013 at 4:46 AM, Andreas Pakulat <an...@fr...>wrote:

> Hi Fabio,
>
> thanks for the hint about the pycompletionserver.py. Currently we
> already have a change or two to PyDev and roll our own but we would
> rather use the official version.
>
> Unfortunately our interpreter is embedded into a commandline tool that
> does not support being used like a normal python interpreter. So thats
> why  choosing it as an interpreter is not suitable at the moment. What
> it does is basically load the main script file (i.e. parse it but does
> not run it immediately), then add a few modules to the python
> interpreter via C API, import those modules into the global namespace of
> the main script file and also import several functions into the global
> namespace. This was done as a convenience for the users but now clearly
> bites back at us when trying to teach PyDev about these specialties.
>

Ok, so, it's not really a custom interpreter, just a different main... Not
sure if that's the best approach (I'd probably go toward a more common
approach of having a different main entry which then would run the script
after configuring the environment, such as most web frameworks do or maybe
a custom sitecustomize).

Still, if you bundle it as an executable, it shouldn't be all that hard to
make it look like a real python interpreter (i.e.: one that could really be
used as an interpreter -- that way you wouldn't need to change PyDev at all
and everything should just work). This is probably the preferred approach.

Now, if that's difficult for you, the
pycompletionserver.py/importsTipper.pyadjustment probably requires
less fiddling to integrate.

Regarding a better approach within PyDev itself, please create a feature
request for that in https://sw-brainwy.rhcloud.com/tracker/PyDev/ (this is
also a request web2py users have -- for which there's a discussed
workaround detailed at the old tracker:
http://sourceforge.net/p/pydev/feature-requests/534/).


>
> Its of course also possible to import those registered modules in the
> script file or in one that is being imported into the main script.
>
> What I ended up doing now which seems to work with 2 caveats (see
> further down) is that I'm using the extension points
> pydev_interpreter_new_custom_entries, pydev_modules_observer and the
> completion extension point. The first one registers the names of the
> modules we add via the C API as 'builtins', the second one adds tokens
> to the __builtin__ module for those modules and the functions we import
> into the global namespace. It also populates our modules with their
> functions when the PyDev code needs them (a script importing our squish
> module for example). All this seems to avoid errors being flagged for
> our Squish API, but does not yet provide the modules and functions for
> completion. Hence using the completion extension point to support that.
>
> The two minor issues with this are:
>
> 1. For the builtins registration using the
> pydev_interpreter_new_custom_entries extension point the users need to
> remove and re-add the interpreter so that PyDev fetches the builtins
> again.
>
> Maybe there's a way to do the above programatically upon startup of a
> plugin?
>
> 2. When using 'import squish' in a script now a warning is flagged
> about this shadowing a builtin module which is correct from what PyDev
> knows but not really happening in the actual interpreter that executes
> the tests.
>
> The second point is not much of a problem as its just a warning and
> hence does not jump out at the user as much as an error (in particular
> an error in script code that Squish just generated).
>
> Andreas
>
>
> On 2013-07-22 22:39, Fabio Zadrozny wrote:
> > Hi Andreas,
> >
> > Actually, if you really have a custom interpreter and this is added
> > in its startup, it's strange that it doesn't work already (PyDev
> > always spawns a shell for the completion and upon startup it'll load
> > the __builtin__ -- or builtins -- module and do a dir() in it).
> >
> > So, if it's custom interpreter, it's mostly a matter of filling the
> > __builtins__ at the startup... If that's not the case, you could
> > change PyDev to add some custom code at the module scope at
> > /org.python.pydev/pysrc/pycompletionserver.py (but you'll have to
> > maintain your own fork if you choose this path).
> >
> > Cheers,
> >
> > Fabio
> >
> > On Fri, Jul 19, 2013 at 12:15 PM, Andreas Pakulat
> > <an...@fr...> wrote:
> >
> >> Hi,
> >>
> >> I'm currently working on improving our usage of PyDev, in particular
> >> starting to let PyDev not only syntax highlight but also analyze the
> >> code our users write. Unfortunately this has one drawback, we use a
> >> custom interpreter and add several global functions to it (this is
> >> done
> >> by having a module for these functions and then importing everything
> >> from this module by default into the global namespace).
> >>
> >> I know about the setting for the PyDev analyzer to not show errors
> >> on
> >> certain undefined functions/variables, but the number of functions
> >> makes
> >> this single lineedit/preference pretty cumbersome to extend.
> >>
> >> I'm wondering wether there's a different way (via code maybe?) to
> >> teach
> >> PyDev about a list of functions it should consider to be
> >> 'predefined',
> >> similar to the builtin modules?
> >>
> >> I'm currently using PyDev 2.6, but could upgrade to 2.7.5 if that
> >> makes
> >> it easier to achieve what I want.
> >>
> >> Andreas
> >>
> >> --
> >> Andreas Pakulat sq...@fr...
> >> froglogic GmbH - Automated UI and Web Testing
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> See everything from the browser to the database with AppDynamics
> >> Get end-to-end visibility with application monitoring from
> >> AppDynamics
> >> Isolate bottlenecks and diagnose root cause in seconds.
> >> Start your free trial of AppDynamics Pro today!
> >>
> >>
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >> [1]
> >> _______________________________________________
> >> pydev-code mailing list
> >> pyd...@li...
> >> https://lists.sourceforge.net/lists/listinfo/pydev-code [2]
> >
> >
> >
> > Links:
> > ------
> > [1]
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&amp;iu=/4140/ostg.clktrk<http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk>
> > [2] https://lists.sourceforge.net/lists/listinfo/pydev-code
> >
> >
> >
> ------------------------------------------------------------------------------
> > See everything from the browser to the database with AppDynamics
> > Get end-to-end visibility with application monitoring from
> > AppDynamics
> > Isolate bottlenecks and diagnose root cause in seconds.
> > Start your free trial of AppDynamics Pro today!
> >
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> >
> > _______________________________________________
> > pydev-code mailing list
> > pyd...@li...
> > https://lists.sourceforge.net/lists/listinfo/pydev-code
>
> --
> Andreas Pakulat sq...@fr...
> froglogic GmbH - Automated UI and Web Testing
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>

Re: [Pydev-code] Add 'global functions' to PyDev analyzer

[Andreas P. <an...@fr...>]

Hi Fabio,

thanks for the hint about the pycompletionserver.py. Currently we 
already have a change or two to PyDev and roll our own but we would 
rather use the official version.

Unfortunately our interpreter is embedded into a commandline tool that 
does not support being used like a normal python interpreter. So thats 
why  choosing it as an interpreter is not suitable at the moment. What 
it does is basically load the main script file (i.e. parse it but does 
not run it immediately), then add a few modules to the python 
interpreter via C API, import those modules into the global namespace of 
the main script file and also import several functions into the global 
namespace. This was done as a convenience for the users but now clearly 
bites back at us when trying to teach PyDev about these specialties.

Its of course also possible to import those registered modules in the 
script file or in one that is being imported into the main script.

What I ended up doing now which seems to work with 2 caveats (see 
further down) is that I'm using the extension points 
pydev_interpreter_new_custom_entries, pydev_modules_observer and the 
completion extension point. The first one registers the names of the 
modules we add via the C API as 'builtins', the second one adds tokens 
to the __builtin__ module for those modules and the functions we import 
into the global namespace. It also populates our modules with their 
functions when the PyDev code needs them (a script importing our squish 
module for example). All this seems to avoid errors being flagged for 
our Squish API, but does not yet provide the modules and functions for 
completion. Hence using the completion extension point to support that.

The two minor issues with this are:

1. For the builtins registration using the 
pydev_interpreter_new_custom_entries extension point the users need to 
remove and re-add the interpreter so that PyDev fetches the builtins 
again.

Maybe there's a way to do the above programatically upon startup of a 
plugin?

2. When using 'import squish' in a script now a warning is flagged 
about this shadowing a builtin module which is correct from what PyDev 
knows but not really happening in the actual interpreter that executes 
the tests.

The second point is not much of a problem as its just a warning and 
hence does not jump out at the user as much as an error (in particular 
an error in script code that Squish just generated).

Andreas


On 2013-07-22 22:39, Fabio Zadrozny wrote:
> Hi Andreas,
>
> Actually, if you really have a custom interpreter and this is added
> in its startup, it's strange that it doesn't work already (PyDev
> always spawns a shell for the completion and upon startup it'll load
> the __builtin__ -- or builtins -- module and do a dir() in it).
>
> So, if it's custom interpreter, it's mostly a matter of filling the
> __builtins__ at the startup... If that's not the case, you could
> change PyDev to add some custom code at the module scope at
> /org.python.pydev/pysrc/pycompletionserver.py (but you'll have to
> maintain your own fork if you choose this path).
>
> Cheers,
>
> Fabio
>
> On Fri, Jul 19, 2013 at 12:15 PM, Andreas Pakulat 
> <an...@fr...> wrote:
>
>> Hi,
>>
>> I'm currently working on improving our usage of PyDev, in particular
>> starting to let PyDev not only syntax highlight but also analyze the
>> code our users write. Unfortunately this has one drawback, we use a
>> custom interpreter and add several global functions to it (this is 
>> done
>> by having a module for these functions and then importing everything
>> from this module by default into the global namespace).
>>
>> I know about the setting for the PyDev analyzer to not show errors 
>> on
>> certain undefined functions/variables, but the number of functions 
>> makes
>> this single lineedit/preference pretty cumbersome to extend.
>>
>> I'm wondering wether there's a different way (via code maybe?) to 
>> teach
>> PyDev about a list of functions it should consider to be 
>> 'predefined',
>> similar to the builtin modules?
>>
>> I'm currently using PyDev 2.6, but could upgrade to 2.7.5 if that 
>> makes
>> it easier to achieve what I want.
>>
>> Andreas
>>
>> --
>> Andreas Pakulat sq...@fr...
>> froglogic GmbH - Automated UI and Web Testing
>>
>> 
>> ------------------------------------------------------------------------------
>> See everything from the browser to the database with AppDynamics
>> Get end-to-end visibility with application monitoring from 
>> AppDynamics
>> Isolate bottlenecks and diagnose root cause in seconds.
>> Start your free trial of AppDynamics Pro today!
>> 
>> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk 
>> [1]
>> _______________________________________________
>> pydev-code mailing list
>> pyd...@li...
>> https://lists.sourceforge.net/lists/listinfo/pydev-code [2]
>
>
>
> Links:
> ------
> [1]
> 
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&amp;iu=/4140/ostg.clktrk
> [2] https://lists.sourceforge.net/lists/listinfo/pydev-code
>
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from 
> AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> 
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
>
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code

-- 
Andreas Pakulat sq...@fr...
froglogic GmbH - Automated UI and Web Testing

Re: [Pydev-code] Add 'global functions' to PyDev analyzer

[Fabio Z. <fa...@es...>]

Hi Andreas,

Actually, if you really have a custom interpreter and this is added in its
startup, it's strange that it doesn't work already (PyDev always spawns a
shell for the completion and upon startup it'll load the __builtin__ -- or
builtins -- module and do a dir() in it).

So, if it's custom interpreter, it's mostly a matter of filling the
__builtins__ at the startup... If that's not the case, you could change
PyDev to add some custom code at the module scope at
/org.python.pydev/pysrc/pycompletionserver.py (but you'll have to maintain
your own fork if you choose this path).

Cheers,

Fabio




On Fri, Jul 19, 2013 at 12:15 PM, Andreas Pakulat <an...@fr...>wrote:

> Hi,
>
> I'm currently working on improving our usage of PyDev, in particular
> starting to let PyDev not only syntax highlight but also analyze the
> code our users write. Unfortunately this has one drawback, we use a
> custom interpreter and add several global functions to it (this is done
> by having a module for these functions and then importing everything
> from this module by default into the global namespace).
>
> I know about the setting for the PyDev analyzer to not show errors on
> certain undefined functions/variables, but the number of functions makes
> this single lineedit/preference pretty cumbersome to extend.
>
> I'm wondering wether there's a different way (via code maybe?) to teach
> PyDev about a list of functions it should consider to be 'predefined',
> similar to the builtin modules?
>
> I'm currently using PyDev 2.6, but could upgrade to 2.7.5 if that makes
> it easier to achieve what I want.
>
> Andreas
>
> --
> Andreas Pakulat sq...@fr...
> froglogic GmbH - Automated UI and Web Testing
>
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> pydev-code mailing list
> pyd...@li...
> https://lists.sourceforge.net/lists/listinfo/pydev-code
>

[Pydev-code] Add 'global functions' to PyDev analyzer

[Andreas P. <an...@fr...>]

Hi,

I'm currently working on improving our usage of PyDev, in particular 
starting to let PyDev not only syntax highlight but also analyze the 
code our users write. Unfortunately this has one drawback, we use a 
custom interpreter and add several global functions to it (this is done 
by having a module for these functions and then importing everything 
from this module by default into the global namespace).

I know about the setting for the PyDev analyzer to not show errors on 
certain undefined functions/variables, but the number of functions makes 
this single lineedit/preference pretty cumbersome to extend.

I'm wondering wether there's a different way (via code maybe?) to teach 
PyDev about a list of functions it should consider to be 'predefined', 
similar to the builtin modules?

I'm currently using PyDev 2.6, but could upgrade to 2.7.5 if that makes 
it easier to achieve what I want.

Andreas

-- 
Andreas Pakulat sq...@fr...
froglogic GmbH - Automated UI and Web Testing

Re: [Pydev-code] J/PythonTest failing

[Fabio Z. <fa...@gm...>]

It seems I broke one of those tests (with an AttributeError:
getNodeUtilsClass). I'll take a look at that (although everything else
should work).

They can be run just as regular junit tests.

Cheers,

Fabio


On Wed, Jul 10, 2013 at 10:51 AM, Andrew Ferrazzutti <afe...@re...>wrote:

> Hi Fabio,
>
> You told me to make sure that the JythonTest and PythonTest java tests
> work, and right now they don't; they either fail or have errors. My
> question is, did they work at some point in the past and something changed
> them? I ask this in case fixing these problems is a matter of restoring
> some older code rather than making new changes. The tests still fail/crash
> even when I have an older commit checked out, so I'm not sure.
>
> Also, should the files be run as JUnit tests or plug-in tests?
>
> Thanks,
> Andrew
>

[Pydev-code] J/PythonTest failing

[Andrew F. <afe...@re...>]

Hi Fabio,

You told me to make sure that the JythonTest and PythonTest java tests work, and right now they don't; they either fail or have errors. My question is, did they work at some point in the past and something changed them? I ask this in case fixing these problems is a matter of restoring some older code rather than making new changes. The tests still fail/crash even when I have an older commit checked out, so I'm not sure.

Also, should the files be run as JUnit tests or plug-in tests?

Thanks,
Andrew

[Pydev-code] Bug 972474 - [abrt] eclipse-pydev-2.7.1-6.fc17: pydev_imports.py:26:<module>:ImportError: No module named queue

[Andrew F. <afe...@re...>]

Hi Andre,

I have some questions about the bug I'm assigned to that you reported (https://bugzilla.redhat.com/show_bug.cgi?id=972474), and about using duplicity to reproduce the bug. Have you ever been able to run duplicity in Eclipse-PyDev before? I ask because running and debugging duplicity with PyDev (following the instructions you provided) always crashes _very_ early on, and on simple things like imports that don't cause errors when running other scripts, leading me to think that maybe there's a problem with running duplicity with Eclipse in general. (I'm able to run duplicity normally in Terminal, but never in Eclipse without an error, with or without arguments.)

Eclipse is also unable to resolve several imports by duplicity files (I get 50 "undefined variable from import" errors), and in many cases I can't find the required components myself. Is there something else I have to install, or to include in my project folder?

I should also mention that I get different errors for running and debugging duplicity; debugging gives me the Queue import error, while running crashes when /bin/duplicity tries to import things. Debugging also causes a dialogue to pop up, telling me that there was an "Unexpected error setting up the debugger". And when I try commenting out the queue import (in pydev_imports) to see how far the script will get, it crashes on other imports, until it fails importing something from the core Python library in root.

Do these kinds of errors happen with different scripts than duplicity?

Thanks for you help,
Andrew

[Pydev-code] RFE: Multiple main modules for Unittest

[Andrew F. <afe...@re...>]

Hi Fabio,

I know it's possible to perform Unittest on multiple modules at once, by selecting multiple items from the Package Manager or by running an entire source folder. However, I don't think there's an option to do that with the Run Configurations menu, as it only allows me to select one module as the Main Module, by mean of a Browse window.

I was thinking of modifying the Browse window to allow it to select multiple modules or source folders. I wouldn't be changing any functionality outside of that menu, as everything else is working fine already. Let me know if you think it's worth undertaking.

Andrew

Re: [Pydev-code] Jython unittest

[Fabio Z. <fa...@gm...>]

It actually depends more on the version you're using... if you're using the
internal Jython in PyDev for tests, then yes, it'll ignore as it has an
older version of Jython/unittest.

Cheers,

Fabio


On Tue, Jul 2, 2013 at 4:56 PM, Andrew Ferrazzutti <afe...@re...>wrote:

> Hi Fabio,
>
> Is Jython's Unittest supposed to work exactly the same as Python's? I ask
> this because Jython ignores any call of setUpClass/setUpModule that I make,
> whereas Python recognizes them.
>
> If Jython isn't supposed to ignore anything, I'll volunteer to add the
> functionality. If the ignoring is fine, though, I'll just push my updates
> as they are (the bug fix with the added test cases you asked for).
>
> Thanks,
> Andrew
>

[Pydev-code] Jython unittest

[Andrew F. <afe...@re...>]

Hi Fabio,

Is Jython's Unittest supposed to work exactly the same as Python's? I ask this because Jython ignores any call of setUpClass/setUpModule that I make, whereas Python recognizes them.

If Jython isn't supposed to ignore anything, I'll volunteer to add the functionality. If the ignoring is fine, though, I'll just push my updates as they are (the bug fix with the added test cases you asked for).

Thanks,
Andrew

Re: [Pydev-code] Java Working Sets in PyDev Package Explorer

[Fabio Z. <fa...@gm...>]

Hi Andrew,

I agree it's a bug and also agree it's not worth fixing it :)

I.e.: to me having a JDT specific working set is the wrong concept in the
first place provided that the platform itself has a working set concept --
IMHO, if JDT devs think some of those features are invaluable, they should
be in the platform, not in JDT -- although given on how things are done in
the Eclipse world, it may be historic: it's not uncommon for some feature
to be created in JDT itself and only later on moved to the platform --
although many times this has side effects such as having one way to do it
in the platform and another in JDT.

Cheers,

Fabio


On Tue, Jun 25, 2013 at 12:17 PM, Andrew Ferrazzutti <afe...@re...>wrote:

> Hi Fabio,
>
> I found an issue with the PyDev Package Explorer. When Working Sets are
> displayed, projects that are inside Java working sets cannot be
> opened/explored in the PyDev Package Explorer. This problem doesn't happen
> with Resource working sets, and when Projects are displayed instead of
> W.Sets. (Obviously, there are no problems with the Java perspective's
> Package Explorer.)
>
> This happens in both my home & child Eclipse, and errors get displayed to
> the home Console when I double-click on a Java folder when using the child.
> Attached is a picture of the PyDev Package Explorer when this problem
> happens. java1 and pyset are Resource working sets, and java2 is a Java
> working set.
>
> To me this seems like a bug, but since Java working sets are optimized for
> Java, maybe it's not that big of an issue. So I'm just telling you about it
> in case it is.
>
> Andrew

[Pydev-code] Java Working Sets in PyDev Package Explorer

[Andrew F. <afe...@re...>]

Hi Fabio,

I found an issue with the PyDev Package Explorer. When Working Sets are displayed, projects that are inside Java working sets cannot be opened/explored in the PyDev Package Explorer. This problem doesn't happen with Resource working sets, and when Projects are displayed instead of W.Sets. (Obviously, there are no problems with the Java perspective's Package Explorer.)

This happens in both my home & child Eclipse, and errors get displayed to the home Console when I double-click on a Java folder when using the child. Attached is a picture of the PyDev Package Explorer when this problem happens. java1 and pyset are Resource working sets, and java2 is a Java working set.

To me this seems like a bug, but since Java working sets are optimized for Java, maybe it's not that big of an issue. So I'm just telling you about it in case it is.

Andrew

Re: [Pydev-code] PyDev Package Explorer & Working Sets

[Fabio Z. <fa...@gm...>]

Hi Andrew,

On Mon, Jun 24, 2013 at 12:09 PM, Andrew Ferrazzutti <afe...@re...>wrote:

> I have a quick question about the PyDev Package Explorer. When I select
> the Top Level Elements to "Working Sets", the Package Explorer doesn't
> behave any differently than when the TLEs are Projects. Also, when "Working
> Sets" is selected, there is no option to "Configure Working Sets" as there
> is for the Java perspective. The only option is to Select/Deselect Working
> Sets, which again, is the same as if Projects are the TLEs. This means that
> the working sets don't appear as folders; instead, all of the projects in
> the selected w.sets appear together.
>

For me it does group working sets properly... but there's a catch: you must
have more than 1 working set active for it to show the working sets as top
level... (otherwise it'll just show the children of the sole working set
you have).


> This happens for both my main & child Eclipse. I also tried enabling some
> Working Set options in the Customize Perspective window, but nothing
> changed. I noticed that other perspectives work this way, too, and that the
> only one that has the "Configure Working Sets" option to display w.sets in
> folders is the Java perspective.
>
> Is this a design choice, or should the Package Explorer work in the same
> way for PyDev as it does for the Java perspective?
>

JDT is heavily customized in this regard (they even have their own concept
of a java working set), and by design PyDev uses what the platform gives.
What you can do to configure your working sets is customize them from the
pydev package explorer: focus it > ctrl+F10 > select working set and there
you can manage your active working sets.

So, if changes are needed in this specific area, the best way to contribute
would probably be porting JDT-specific things to the Eclipse base CNF
(Common Navigation Framework).

Cheers,

Fabio

[Pydev-code] PyDev Package Explorer & Working Sets

[Andrew F. <afe...@re...>]

I have a quick question about the PyDev Package Explorer. When I select the Top Level Elements to "Working Sets", the Package Explorer doesn't behave any differently than when the TLEs are Projects. Also, when "Working Sets" is selected, there is no option to "Configure Working Sets" as there is for the Java perspective. The only option is to Select/Deselect Working Sets, which again, is the same as if Projects are the TLEs. This means that the working sets don't appear as folders; instead, all of the projects in the selected w.sets appear together.

This happens for both my main & child Eclipse. I also tried enabling some Working Set options in the Customize Perspective window, but nothing changed. I noticed that other perspectives work this way, too, and that the only one that has the "Configure Working Sets" option to display w.sets in folders is the Java perspective.

Is this a design choice, or should the Package Explorer work in the same way for PyDev as it does for the Java perspective?

Re: [Pydev-code] General questions about PyDev

[Fabio Z. <fa...@gm...>]

On Mon, Jun 24, 2013 at 10:51 AM, Andrew Ferrazzutti <afe...@re...>wrote:

> On Sat, Jun 22, 2013 at 2:31 PM, Andrew Ferrazzutti <afe...@re...
> >wrote:
> >> Is there a reason why my child Eclipse is getting two run buttons?
>
> >Can you add a snapshot? (I'm not really visualizing what you mean here).
> >Cheers,
> >Fabio
>
> As I promised, attached are some screenshots regarding this issue. The
> first image shows the extra Run button, and the other is the message I get
> when I press it. The extra button only appears in my child Eclipse on this
> computer.
>

Not sure what is giving you this menu... if you use the window > customize
perspective action, you should be able to inspect the menus/commands to
discover what that is...


>
> >If you feel adventurous, a common request would be a wizard to create a
> >pydev project from existing sources (in which case it should analyze the
> >folder given for packages -- i.e.: dirs with __init__.py folders or just
> >folders with .py files and set the root as a source folder accordingly).
>
> Thanks for the suggestion! After I add to the New Project wizard I'll give
> this a shot. (And thanks for the list of related wizard classes.)
>
> Andrew
>
> PS: I'll be communicating through the mailing list from now on.