Python interpreter per-project feature

View: New views
2 Messages — Rating Filter:   Alert me  

Python interpreter per-project feature

by Raul Fernandes Herbster-3 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hi,

congratulations for the latest release... important features were implemented :)

As I explained a couple of weeks ago, I need a suitable Python interpreter. For example, I need to launch the information about the modules of a certain Python interpreter on a remote environment, for example. Then, a different method to obtain such information are necessary. This was already resolved (I had to implement another class from AbstractInterpreterManager).

However, I faced another problem: depending of the remote environment (for example: a) installed on the same machine, but accessed through different commands or b) installed on a remote machine, and accessed though SSH commands), the InterpreterInfos of a certain python interpreter can be obtained in different ways (my XXInterpreterManager knows how to deal with it).  The point is that Pydev is using the path to the project's interpreter (from PythonNature#getProjectInterpreter) as the key to finding its unique configuration (ID == path location == executable). In a nutshell: why don't the python interpreter, instead of a string, can be implemented as a class (with attributes , such as display string, the path location and the ID)? And, on AbstractInterpreterManager#internalCreateInterpreterInfo(), instead of using a executable, can receive a PytonInterpreter (the new class)? I'm just finish a patch to sent you and wait for comments :)

[]'s
--Raul



------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
pydev-code mailing list
pydev-code@...
https://lists.sourceforge.net/lists/listinfo/pydev-code

Re: Python interpreter per-project feature

by Fabio Zadrozny-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

> As I explained a couple of weeks ago, I need a suitable Python interpreter.
> For example, I need to launch the information about the modules of a certain
> Python interpreter on a remote environment, for example. Then, a different
> method to obtain such information are necessary. This was already resolved
> (I had to implement another class from AbstractInterpreterManager).
>
> However, I faced another problem: depending of the remote environment (for
> example: a) installed on the same machine, but accessed through different
> commands or b) installed on a remote machine, and accessed though SSH
> commands), the InterpreterInfos of a certain python interpreter can be
> obtained in different ways (my XXInterpreterManager knows how to deal with
> it).  The point is that Pydev is using the path to the project's interpreter
> (from PythonNature#getProjectInterpreter) as the key to finding its unique
> configuration (ID == path location == executable). In a nutshell: why don't
> the python interpreter, instead of a string, can be implemented as a class
> (with attributes , such as display string, the path location and the ID)?
> And, on AbstractInterpreterManager#internalCreateInterpreterInfo(), instead
> of using a executable, can receive a PytonInterpreter (the new class)? I'm
> just finish a patch to sent you and wait for comments :)


That seems fine for me. Please add a patch to the sourceforge tracker
(but please make sure that it is backward compatible and users won't
loose all their configured interpreters).

Cheers,

Fabio

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
pydev-code mailing list
pydev-code@...
https://lists.sourceforge.net/lists/listinfo/pydev-code