Re: [PyWrapper-devel] Libraries distribution in PyWrapper

SourceForge Headquarters 225 Broadway Suite 1600 San Diego, CA 92101 +1 (858) 422-6466

Yes, it works for me...

SOAPpy and biomoby are pure Python so we can bundle.

I think mxDateTime as you said is fine... the proble is if you use the
odbc stuff if I remember... so this one can not even be distributed,
it MUST be downloaded from their site... apart of this I think we can
include all of them in PyWrapper and create an installer scripts that
does the work for the user...

With this I will be satisfied... also we will have much more control
over the libraries versions...

And now an even more dramatic suggestion... what about including
Python itself also? So in Windows in easy, you just have to run the
installer (PyWrapper) and everything, including Pthon is installed for
you in a folder, we dont touch anything.
In Unix we can create an installer that installs python and all
requiered libraries under our folder...

I know it is not the most common way of distributing applications, but
if this is gonna get deploy in so many places this looks like it will
save us some headaches...

Now Markus I know will not like the idea :D

Cheers.

On 8/2/06, "D=F6ring, Markus" <m.d...@bg...> wrote:
> Javi,
> you are perfectly right. its getting horrible.
> Actually Ive already bundled a library with pywrapper. Everything under l=
ib which is not biocase/ is external stuff.
> So we should go through the required libs and if they do not need to be c=
ompiled, so if they are pure python, we can simply add them to our lib fold=
er!
>
> But
> > 1)PyXML
> > 2)mxDateTime
> > 3)CherryPy
> need to be compiled for sure
>
> with
> > 4)elementtree
> > 5)kid
> and your additional ones we need to check.
> SOAPpy for example I think is pure python.
>
>
> In case users have these libraries installed in their system, we might ge=
t into trouble.
> But if we make sure (which I think is the case already!) that our lib pat=
h comes before the regular system lib path in sys.path, then our libs will =
be imported.
>
> For example:
> http://search.biocase.org/tapir/configtool/environment
>
> shows our loib folder before the others:
> ['/home/biocase/tapir/lib/biocase/..', '/home/biocase/tapir/lib', '/home/=
biocase/tapir/webapp', '/usr/lib/python24.zip', '/usr/lib/python2.4', '/usr=
/lib/python2.4/plat-linux2', '/usr/lib/python2.4/lib-tk', '/usr/lib/python2=
.4/lib-dynload', '/usr/local/lib/python2.4/site-packages', '/usr/lib/python=
2.4/site-packages', '/usr/lib/python2.4/site-packages/setuptools-0.6a7-py2.=
4.egg', '/usr/lib/python2.4/site-packages/kid-0.9-py2.4.egg', '/usr/lib/pyt=
hon2.4/site-packages/wsgiref-0.0.1-py2.4.egg']
>
>
> For the compiled libs I would suggest:
>
> 1) create a compiled version for windows
> 2) include the source installers in our package, so people dont have to g=
o and look for the right version.
>
>
> With mx.DateTime we need to get in touch with eGenix. I know they dont li=
ke the idea in general (they've been contacting me during biocase times). B=
ut if we dont use the entire mxEgenixBase package, but only mxDateTime, the=
y might be OK. it comes with linux distributions anyways.
>
> Does this work for you?
>
> -- Markus
>
>
> > -----Urspr=FCngliche Nachricht-----
> > Von: pyw...@li...
> > [mailto:pyw...@li...] Im
> > Auftrag von Javier privat
> > Gesendet: Mittwoch, 2. August 2006 12:24
> > An: PyWrapper Developers mailing list
> > Betreff: [PyWrapper-devel] Libraries distribution in PyWrapper
> >
> > Hi,
> >
> > I was wondering if we could change a bit our strategy for
> > deploying PyWrapper. Right now to install it you have to install:
> >
> > 1)PyXML
> > 2)mxDateTime
> > 3)CherryPy
> > 4)elementtree
> > 5)kid
> >
> > Then you probably will also need:
> >
> > 6) libxml2
> > 7) a database module
> >
> > and finally if you want BioMOBY support now I will also be requiring:
> >
> > 8) fpconst
> > 9) SOAPpy
> > 10) BioMOBY Python
> >
> > This is getting a little bit horrible to install. I think
> > most of these libraries, I think actually all, can be legally
> > redistributed with other software so I was wondering if we
> > could not embed everything into PyWrapper.
> >
> > Well, I know there are some problems. Some of these libraries
> > need to be compiled in unix and therefore installation is
> > needed. But in Windows we might be able to distribute them
> > already compiled. In the case of unix we can at least include
> > them in the package and provide an installer that install all
> > of them into our external_lib directory.
> >
> > We can have something like /lib/external_lib folder where we
> > include all this stuff. Do you know what happens if we
> > install a certain version of a library there and the user has
> > already the same library installed on his python? Which one
> > will take preference?
> >
> > And there is still the open issue of which library to use for xslt...
> > we are not happy with none of them and they are all difficult
> > to install in mac os x. Any ideas?
> >
> > Cheers.
> >
> > --------------------------------------------------------------
> > -----------
> > Take Surveys. Earn Cash. Influence the Future of IT Join
> > SourceForge.net's Techsay panel and you'll get the chance to
> > share your opinions on IT & business topics through brief
> > surveys -- and earn cash
> > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge
> &CID=3DDEVDEV
> > _______________________________________________
> > PyWrapper-devel mailing list
> > PyW...@li...
> > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel
> >
>