Greg,
First, thank you very much for your help.
As your told me, it was a problem with environment variables.
Eclipse works now!! and it is easier than I thought. I'll try to explain the way I did it, but sorry about my bad english, I hope you understand what I say.
1)Eclipse: Window (menu) > Preferences...
   I seted Python interpreter: ...\chimera\bin\python.exe
   Then I included chimera "share" directory in PYTHONPATH option.
   Then choose apply and ok.
2)Once I have created a new project, and a new python file or module was created:
  Go to the Run As (menu option) clicking with right mouse button on the python module.
  Then select Run ... option and select your file in the Python Run (subtree).
  Select Enviroment (tab) and mark option "Replace native environment with especified environment. I THINK THAT IS  KEY STEP...
 (Finally you could go to the Refresh tab and apply it to the entire workspace).

Well, I think it should works for everybody running Windows or Linux.

Thank you so much we keep in contact.

Javi.


On 10/2/06, Greg Couch <gregc@cgl.ucsf.edu> wrote:
We haven't used eclipse with chimera, but we will work with you to get it
to work.  When it does work, please send what you had to do back to the
chimera-dev list.

First an aside for non-eclipse users and maybe this would work in eclipse
too -- you can use Python's help facility to find out more about chimera
internals: in an IDLE window, typing:

         help(chimera.Point)

will give you a lot information about the Point API.  Since Point is
implemented in C++, you only get the type information for the arguments
and the return value, but that information, coupled with the name of the
method, tell you a lot.

Back to eclipse, the chimera program sets up several environment variables
before invoking python.  On Linux, it is a shell script and you can see
everything it does.  On Windows, it's basically the same:

        (1) set the CHIMERA environment variable to the actual path of the
                chimera install tree (so without any symbolic links).
        (2) make sure CHIMERA/bin is in the PATH environment
        (3) defensively remove the PYTHONHOME and PYTHONPATH environment
                variables so we don't get packages compiled for a
                different version of python (e.g, the system one)
        (4) copy CHIMERPATH environment variable to the PYTHONPATH one
        (5) set Tcl environment variables:
                TCL_LIBRARY is CHIMERA\lib\tcl8.4
                TCLLIBPATH is {CHIMERA\lib}
        (6) unset TK_LIBRARY and TIX_LIBRARY environment variables

Unix systems replace step 2 with one that set the environment variable for
finding shared libaries, ie., LD_LIBRARY_PATH or DYLD_LIBRARY_PATH or ...
to CHIMERA/lib.  On OS X, we also set the DYLD_FRAMEWORK_PATH.

        Good luck,

        Greg Couch
        UCSF Computer Graphics Lab

On Mon, 2 Oct 2006, Javier Díez wrote:

> Date: Mon, 2 Oct 2006 20:38:53 +0200
> From: "[ISO-8859-1] Javier Díez" < jdiezperezj@gmail.com>
> To: Eric Pettersen <pett@cgl.ucsf.edu>
> Cc: chimera-dev@cgl.ucsf.edu
> Subject: Re: [chimera-dev] chimera import
>
> Hi again,
> Thank you for your comments. From now I will never use the import
> construction I wrote above.
> But I have got another question.
> Well, I'm using Eclipse and PyDev Extensions, and I seted the Eclipse Python
> interpreter option using the Python version included in Chimera.
> I also included the "share" in the Eclipse, PyDev PYTHONPATH, but it doesn't
> works.
> I thought it could work, but it doesn't.
> I prefer Eclipse (because it is the enviroment  I'm used to work with) to
> the IDLE provided by Chimera.
> Thank you any way.
> Javi
>
> On 10/2/06, Eric Pettersen <pett@cgl.ucsf.edu> wrote:
>>
>> Tom Goddard's comments are exactly correct, I just want to add some
>> advice.  If anyone else will be working on your code, you should try to
>> avoid the "from module_name import *" construct because it makes it more
>> difficult to find the place where a class is defined.  Say for example you
>> use a Point object in your code.  A person trying to find the definition
>> for
>> Point first has to look through the file using Point to see if it's defined
>> there, then through each module from which you've imported "*" to look for
>> it.  It is better to import just the names you are going to use, something
>> like:  "from chimera import Point, openModels, Molecule".  That statement
>> makes it clear where the definition of Point is going to be found.
>> The other thing is that the "chimera" module imports all the names from
>> _chimera, so typically you import from chimera rather than _chimera.  I
>> know
>> that the chimera uses the "from _chimera import *" construct, which seems
>> somewhat hypocritical given the advice above, but it is being used to make
>> C++ classes/functions that "logically" belong in the chimera module
>> available.
>>
>> --Eric
>>
>>                         Eric Pettersen
>>
>>                         UCSF Computer Graphics Lab
>>
>>                         pett@cgl.ucsf.edu
>>
>>                         http://www.cgl.ucsf.edu
>>
>>
>> On Oct 2, 2006, at 5:44 AM, Javier Díez wrote:
>>
>> Hy,
>> I've just started working on a Chimera extension.
>> I've tried to import chimera after setting up the CHIMERA os variable, but
>> it gives me this erro message:
>> ***from _chimera import *
>> ImportError: No module named _chimera
>> *Some help?
>> Thank you.
>> Javi
>> *
>> *
>> _______________________________________________
>> Chimera-dev mailing list
>> Chimera-dev@cgl.ucsf.edu
>> http://www.cgl.ucsf.edu/mailman/listinfo/chimera-dev
>>
>>
>>
>