On 9/16/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
Andrew Borley wrote:
> Good to hear you got it going! :-)
> To answer your questions:
>
>
> On 9/13/06, Jean-Sebastien Delfino <[EMAIL PROTECTED]> wrote:
>> Jean-Sebastien Delfino wrote:
>> > Jean-Sebastien Delfino wrote:
>> >
>> > 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?
>
> It looks like python loads the module when it finds an 'import
> TuscanySCA'
> statement in the script. Python looks on the PYTHONPATH envronment
> variable
> for either a TuscanySCA.py script, a TuscanySCA.pyc compiled script or a
> TuscanySCA.dll (or .pyd on Windows and .so on Linux). If it finds a
> library,
> python then finds and invokes the initTuscanySCA exported method which
> sets
> up the methods, and variables available in the module.
>
> So the answer to your 1st and 3rd questions is that the
> TuscanySCASetup.pybuild just compiles the
> TuscanySCAModule.cpp file, and depends on the tuscany_sca_python.lib
> (libtuscany_sca_python.so on Linux) being pre-built. We could compile all
> the extension code into a single library, but it would need to be named
> TuscanySCA.dll (or TuscanySCA.so) for "import TuscanySCA" to work. We
> could
> rename the module to tuscany_sca_python (e.g. "import
> tuscany_sca_python")
> and build a single tuscany_sca_python.dll or tuscany_sca_python.so,
> but the
> runtime currently depends on extension libraries on linux being named
> libLibraryName.so so I don't know if it would work.
> What happens on Linux if you rename TuscanySCA.so to libTuscanySCA.so?
> Can
> python still find the module?
>
> The answer to your 2nd question is that we can install the
> TuscanySCA.so and
> the TuscanySCAProxy.py to a different directory (I didn't realise
> /usr/lib/python.../site-packages would be root only on Linux) using a
> command like:
>
> python TuscanySCASetup.py install --install-lib
> $TUSCANY_SCACPP/extensions/python/lib
>
> and then get users to add $TUSCANY_SCACPP/extensions/python/lib to their
> PYTHONPATH.
> I have updated the build files and PythonCalculator sample on Windows and
> Linux to do this.
>
>
>> 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!
>
> Great! Glad to hear it worked OK :)
>
>
> In other news, I have just added in support for properties to the Python
> extension:
> - A composite with a property defined in a component and the associated
> .componentType file:
> <component name="DivideComponent">
> <implementation.python module="DivideImpl" scope="composite"/>
> <property name="doRounding">true</property>
> </component>
>
> <componentType
> ...
> <property name="doRounding" type="xsd:boolean"/>
> </componentType>
>
> Is automatically instantiated and assigned the property value in the
> python
> implementation module:
>
> def divide(val1, val2):
> result = float(val1) / float(val2)
> print "Python - DivideImpl.divide " + str(val1) + " / " + str(val2)
> + "
> = " + str(result)
>
> # Use the doRounding property
> if doRounding:
> result = round(result)
> print "Python - DivideImpl.divide is rounding the result to " +
> str(result)
>
> return result
>
>
> Cheers
>
> Andy
>
Andy,
I adjusted the Linux Automake build to integrate your Python extension
as follows:
- TuscanySCAModule.cpp is now built into libtuscany_sca_python.so.
- The make install creates a symbolic link TuscanySCA.so ->
libtuscany_sca_python.so.
- TuscanySCAProxy.py is now distributed beside the library in
extensions/python/lib.
- Users can point their PYTHONPATH to extensions/python/lib, I added
that setting to the runclient script.
This seems to work out the box just with the unzipped distro. No need to
do any post install step you can run the PythonCalculator right away.
TuscanySCAProxy.py gets compiled into a .pyc automatically the first
time it's invoked.
That sounds good - unfortunately Windows doesn't support sym links, so
we have to have a slightly different process. The current build
creates TuscanySCA.dll from TuscanySCAModule.cpp only and puts it and
TuscanySCAProxy.py into extensions/python/bin.
If a user wants to install the Python module lib into
/usr/lib/python/site-packages and get TuscanSCAProxy pre-compiled then
he can still run a setup -install script. Do you think we should package
TuscanySCASetup.py in the distro and where do you think it should go?
extensions/python/bin? anywhere else?
I think extensions/python/bin would be the right place - we may also
need a .sh file to run TuscanySCASetup.py in the right way - so it can
find the compiled library and scripts. Alternatively, what we could do
for binary releases is use the bdist_rpm option in the build to create
an installable RPM containing the library and extension. There is a
bdist_wininst option that does something similar on windows.
Lastly, I think it would nice if we could name the module just sca and
leave the Tuscany out (like we do in CPP, Java etc.). The client API
would be sca.locateService(...). Also I looked at other python packages
and most of them seem to be lowercase so that's why I'm proposing "sca"
instead of "SCA" like we have in Ruby (where module names start with an
uppercase letter).
What do you think?
Yep, I'm good with that too. You don't think it's a bit presumptious
to say "sca on Python" == Tuscany? Let's do it and see when/if people
complain ;-)
Andy
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
