Jean-Sebastien Delfino wrote:
Jean-Sebastien Delfino wrote:
Andrew Borley wrote:
Hi all,
I've just checked in code to support SCA clients written in Python and
references in Python components.
The updated PythonCalculator sample under
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/PythonCalculator<http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/samples/RubyCalculator/sample.calculator/>
shows the programming model:
- A client can get a proxy to a service with:
import TuscanySCA
and
calculator = TuscanySCA.locateService
("CalculatorComponent/CalculatorService")
- You then simply call a business method on "calculator", like this:
x = calculator.add(1, 2)
- References are automatically added to your Python component
implementation
when the runtime loads the implementation script, so they can be
used like
so:
# The module-level div function
def div(val1, val2):
# Use the divideService reference
result = divideService.divide(val1, val2)
return result
and in your composite file:
<component name="CalculatorComponent">
<implementation.python module="CalculatorImpl" scope="composite"/>
<reference
name="divideService">DivideComponent/DivideService</reference>
</component>
- Due to the current requirement of a componentType file, I have
implemented
an empty interface.python interface extension (rather than expecting
people
to use interface.cpp or something. So a .componentType file would
look like:
<componentType xmlns="http://www.osoa.org/xmlns/sca/1.0";>
<service name="CalculatorService">
<interface.python/>
</service>
<reference name="divideService">
<interface.python/>
</reference>
</componentType>
- The client and reference support comes from a Python extension
package
that is installed into the Python environment, making the TuscanySCA
and
TuscanySCAProxy modules available for all python scripts.
- Next up is properties support - this should be pretty easy.
- Further work would be to look at annotations, to avoid the need
for the
.componentType files at all.
The code for the Tuscany/C++ Python extension is here:
http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/python<http://svn.apache.org/repos/asf/incubator/tuscany/cpp/sca/runtime/extensions/ruby/>
It builds and runs fine on Windows (remember to have the PYTHON_HOME
env
variable set to your Python insallation dir), but hasn't been tested or
built on Linux. I have updated the automake files but I don't know
how to
add in the commands to build and install the Python extension into
Python.
The commands required are:
cd tuscany/cpp/sca/runtime/extensions/python/src/tuscany/sca/python
python TuscanySCASetup.py build
python TuscanySCASetup.py install
If someone who knows automake could add these in and test it out
that would
be great!
Cheers
Andy
Andy,
Looks great! I can help integrate in the automake build.
Andy,
I got your Python library building on Linux. It's pretty cool and I'm
now trying to integrate the building of TuscanySCA.so, but I have a
few quick questions:
- TuscanySCASetup.py build just seems to do a normal compile, do I
need to use it, or do you think that I can just get
TuscanySCAModule.cpp compiled with the other .cpp in the same
directory by just adding it to the list of .cpp files in Makefile.am?
- TuscanySCASetup install wants to install under
/usr/lib/python.../site-packages. This only works for the root user,
and more generally looks like it should be run as part of the install
of the Tuscany distribution, instead of the build. Does it do anything
else than copying files to site-packages? Is there a way to tell the
python interpreter where to find additional modules in addition to the
/usr/lib/python.../site-packages? Do you think we could just
distribute TuscanySCA.so and the TuscanyProxy.py under the tuscany
distribution directory, and then ask Python application developers to
just add that dir to their python path or something like that?
- Is there a particular reason for having two separate .so files
libtuscany_sca_python.so and TuscanySCA.so? or could these two be
combined in a single .so file?
Thanks...
Andy,
Besides the build integration related questions above, I confirm that
your Python extension works great on Linux (tested on Redhat Enterprise
Linux 4). The only change I had to make was to remove an include of
"...cpp/model/CPPInterface.h" in PythonServiceProxy.cpp. I committed
that small fix under revision r443083. Nice!
--
Jean-Sebastien
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
