[chimera-dev] chimera import
Javier Díez
jdiezperezj at gmail.com
Tue Oct 3 03:19:11 PDT 2006
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 at 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 at gmail.com>
> > To: Eric Pettersen <pett at cgl.ucsf.edu>
> > Cc: chimera-dev at 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 at 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 at 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 at cgl.ucsf.edu
> >> http://www.cgl.ucsf.edu/mailman/listinfo/chimera-dev
> >>
> >>
> >>
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://plato.cgl.ucsf.edu/pipermail/chimera-dev/attachments/20061003/cfe6cb77/attachment.html>
More information about the Chimera-dev
mailing list