pywrapper-devel Mailing List for pywrapper (Page 9)
Status: Alpha
Brought to you by:
jatorre
Menu
▾
▴
pywrapper-devel — PyWrapper Developers mailing list
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
(10) |
Apr
|
May
(4) |
Jun
|
Jul
(40) |
Aug
(20) |
Sep
|
Oct
(10) |
Nov
(112) |
Dec
(18) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(8) |
Feb
|
Mar
|
Apr
(6) |
May
(13) |
Jun
(12) |
Jul
(5) |
Aug
|
Sep
|
Oct
|
Nov
(3) |
Dec
(3) |
| 2008 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(3) |
Jun
(3) |
Jul
(6) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Renato De G. <re...@cr...> - 2006-08-04 14:26:15
|
Hi,
It's possible to handle LIKEs, but the SQL expression can look a bit
ugly if your translation table is big. Instead of comparing the
search value directly with the field value, you need to compare it
with a nested CASE expression such as:
SELECT ... FROM ... WHERE (CASE WHEN field =3D 'xxx' THEN ('aaa') ELSE
(CASE WHEN field =3D 'yyy' THEN 'bbb' ELSE null END) END) like 'a%';
Definitely not the best performance, but it should work.
Regards,
--
Renato
On 27 Jul 2006 at 10:46, Markus D=F6ring wrote:
>
> hi,
> id like to implement searching on schema enumerations.
> I allow to setup a translation between local database terms and
> schema/concept terms.
> So when searching I need to translate the argument as well. Thats
> horrible for LIKEs. So I will only allow an equal operation for now
> on enumerations. Do you think this is very bad?
>
> Markus
|
|
From: Javier de la T. <ja...@gm...> - 2006-08-03 11:56:13
|
Regarding ant... I remember that I had to install ant to be able to install another software and I did not like this. Probably is included in most Linux distros, but in mac os x is not. I think I prefer the typical: ./configure --with-mysql=3D/usr/local/mysql/lib make make install And nothing special for mac os x. Cheers. On 8/3/06, Javier de la Torre <ja...@gm...> wrote: > I have it ready... I have a simple installer using just the shell... > > I have put it under: > http://www.pywrapper.org/PyWrapperInstaller.zip > > Uncompress it and adapt the line 10: > ./configure --prefix=3D/Users/javi/workspace/temp/PyWrapper/python > > And adapt it to wherever you have uncompress the file (adapt only > until python!!) > > What this package does is just with a single installer, install python > 2.4 in a folder and then install all the other libraries on this > python installation. > > It does not include PyWrapper at the moment, but is just for you to > figure out. Then we have a totally controlled environment and a happy > user becuase we haven't touched anything on their system.... > > It takes some time to install and compile everything but I have seen > much worst installations :D > > It still have pending the installation of libxml and db modules, but I > think we can figure out how to do this by asking th user which > database is he going to use and asking for the folder where the shared > libraries are. > > For Windows I think we dont have to worry about anything, the python > installer in Windows is not compiling!! Is just copying the files, we > will do the same. Is the same trick I did with the installer for BPS2. > > Cheers. > > On 8/3/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > > theres make and ant. ant is newer and more powerful (I think). > > > > the start_server.py script is like the shell script. > > we can modify it to accept an optional port to run under, defaulting to= 8080 or so. good idea! > > > > I still dont know how db_modules will work if they depend on the instal= lation of the target system. > > I hope we dont ned to build python for windows ourselves. thats horribl= e, it needs the commercial MS Visual C++ compiler. > > http://uucode.com/texts/python-mingw/python-mingw.html > > > > cherrypy is needed for all webapps! > > but you can run it behind mod_python (maybe thats broken now, but you s= hould be able to) if you like. > > > > BTW, there a doc about embedding python in your application that I have= nt read: > > http://docs.python.org/ext/ext.html > > > > > > -- Markus > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: pyw...@li... > > > [mailto:pyw...@li...] Im > > > Auftrag von Javier privat > > > Gesendet: Donnerstag, 3. August 2006 12:38 > > > An: PyWrapper Developers mailing list > > > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper > > > > > > Ok, in Windows is clear, I think we should provide an > > > installer that installs everything, python and all libraries. > > > Aditionally will be nice to have a little interface to start > > > and stop cherrypy server if they want to use it instead of > > > their existing server. I like it because people can try > > > things very fast without having to configure anything. > > > > > > For Mac I would treat it as Linux, it is enough to have to > > > take care of two things! I was actually thinking on a > > > configure file that looks for dependencies of the database > > > modules and where you can pass as arguments the location of > > > them. Then something like build that compiles python and all > > > libraries in our own folder, not touching anything of the > > > host machine. Me as a user I prefer to not have to touch my > > > python to install pywrapper, I prefer that everything stays > > > into one single folder that I can send to the trash when I > > > want to uninstall. > > > > > > And then I would have a script to start cherrypy, like the > > > start_server.py that we have but that is a shell script and > > > that I can pass the port where I want the server to run in. > > > > > > Correct me, if I am wrong, will the config tool work outside > > > of cherrypy? > > > > > > Cheers. > > > > > > PD: What is the difference/advantages of build and ant? > > > > > > On 8/3/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > > > > in java for sure. In python its modules. But I saw in > > > CheeseShop that they call it packages as well. I will rename > > > it, good choice! > > > > > > > > -- Markus > > > > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > > Von: pyw...@li... > > > > > [mailto:pyw...@li...] Im Auftrag > > > > > von Javier privat > > > > > Gesendet: Mittwoch, 2. August 2006 21:56 > > > > > An: D=F6ring, Markus > > > > > Cc: PyWrapper Developers mailing list > > > > > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrappe= r > > > > > > > > > > In other software I have seen calling it "packages" > > > > > > > > > > Cheer.s > > > > > > > > > > On 02/08/2006, at 14:40, D=F6ring, Markus wrote: > > > > > > > > > > > So lets include a new directory called "installer" in > > > the project. > > > > > > If we dont like the name we can change it later, but I cant > > > > > think of > > > > > > any better right now. > > > > > > I will add some of the libs already. But remember to > > > only use the > > > > > > source installers, never the comiled stuff. > > > > > > > > > > > > -- Markus > > > > > > > > > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > > > >> Von: pyw...@li... > > > > > >> [mailto:pyw...@li...] Im > > > > > Auftrag von > > > > > >> D=F6ring, Markus > > > > > >> Gesendet: Mittwoch, 2. August 2006 14:31 > > > > > >> An: PyWrapper Developers mailing list; Javier privat > > > > > >> Betreff: Re: [PyWrapper-devel] Libraries distribution in > > > > > >> PyWrapper > > > > > >> > > > > > >> mx.DateTime alone is also open source. > > > > > >> http://www.egenix.com/files/python/mxDateTime.html#Copyright > > > > > >> > > > > > >> their own kind of license, but I cant see any problem > > > > > >> distributing > > > > > >> it: > > > > > >> http://www.egenix.com/files/python/mxLicense.html#Public > > > > > >> > > > > > >> > > > > > >> -- 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 PyWrappe= r > > > > > >>> > > > > > >>> 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=3Dsource= forge > > > > > >> &CID=3DDEVDEV > > > > > >>> _______________________________________________ > > > > > >>> PyWrapper-devel mailing list > > > > > >>> PyW...@li... > > > > > >>> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > > > > >>> > > > > > >> > > > > > >> -------------------------------------------------------------- > > > > > >> ----------- > > > > > >> 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=3Dsourcef= orge > > > > > > &CID=3DDEVDEV > > > > > >> _______________________________________________ > > > > > >> PyWrapper-devel mailing list > > > > > >> PyW...@li... > > > > > >> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > > > > >> > > > > > > > > > > > > > > > -------------------------------------------------------------- > > > > > ----------- > > > > > 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=3Dsourceforg= e > > > > &CID=3DDEVDEV > > > > > _______________________________________________ > > > > > PyWrapper-devel mailing list > > > > > PyW...@li... > > > > > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > > > > > > > > > > > > > > > ---------------------------------------------------------------------= - > > > > --- 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&CI= D=3DDEV > > > > DEV _______________________________________________ > > > > PyWrapper-devel mailing list > > > > PyW...@li... > > > > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > > > > > > > > > -------------------------------------------------------------- > > > ----------- > > > 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 > > > > > > > -----------------------------------------------------------------------= -- > > 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 > > > |
|
From: Javier de la T. <ja...@gm...> - 2006-08-03 11:42:48
|
I have it ready... I have a simple installer using just the shell... I have put it under: http://www.pywrapper.org/PyWrapperInstaller.zip Uncompress it and adapt the line 10: ./configure --prefix=3D/Users/javi/workspace/temp/PyWrapper/python And adapt it to wherever you have uncompress the file (adapt only until python!!) What this package does is just with a single installer, install python 2.4 in a folder and then install all the other libraries on this python installation. It does not include PyWrapper at the moment, but is just for you to figure out. Then we have a totally controlled environment and a happy user becuase we haven't touched anything on their system.... It takes some time to install and compile everything but I have seen much worst installations :D It still have pending the installation of libxml and db modules, but I think we can figure out how to do this by asking th user which database is he going to use and asking for the folder where the shared libraries are. For Windows I think we dont have to worry about anything, the python installer in Windows is not compiling!! Is just copying the files, we will do the same. Is the same trick I did with the installer for BPS2. Cheers. On 8/3/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > theres make and ant. ant is newer and more powerful (I think). > > the start_server.py script is like the shell script. > we can modify it to accept an optional port to run under, defaulting to 8= 080 or so. good idea! > > I still dont know how db_modules will work if they depend on the installa= tion of the target system. > I hope we dont ned to build python for windows ourselves. thats horrible,= it needs the commercial MS Visual C++ compiler. > http://uucode.com/texts/python-mingw/python-mingw.html > > cherrypy is needed for all webapps! > but you can run it behind mod_python (maybe thats broken now, but you sho= uld be able to) if you like. > > BTW, there a doc about embedding python in your application that I havent= read: > http://docs.python.org/ext/ext.html > > > -- Markus > > > > -----Urspr=FCngliche Nachricht----- > > Von: pyw...@li... > > [mailto:pyw...@li...] Im > > Auftrag von Javier privat > > Gesendet: Donnerstag, 3. August 2006 12:38 > > An: PyWrapper Developers mailing list > > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper > > > > Ok, in Windows is clear, I think we should provide an > > installer that installs everything, python and all libraries. > > Aditionally will be nice to have a little interface to start > > and stop cherrypy server if they want to use it instead of > > their existing server. I like it because people can try > > things very fast without having to configure anything. > > > > For Mac I would treat it as Linux, it is enough to have to > > take care of two things! I was actually thinking on a > > configure file that looks for dependencies of the database > > modules and where you can pass as arguments the location of > > them. Then something like build that compiles python and all > > libraries in our own folder, not touching anything of the > > host machine. Me as a user I prefer to not have to touch my > > python to install pywrapper, I prefer that everything stays > > into one single folder that I can send to the trash when I > > want to uninstall. > > > > And then I would have a script to start cherrypy, like the > > start_server.py that we have but that is a shell script and > > that I can pass the port where I want the server to run in. > > > > Correct me, if I am wrong, will the config tool work outside > > of cherrypy? > > > > Cheers. > > > > PD: What is the difference/advantages of build and ant? > > > > On 8/3/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > > > in java for sure. In python its modules. But I saw in > > CheeseShop that they call it packages as well. I will rename > > it, good choice! > > > > > > -- Markus > > > > > > > > > > -----Urspr=FCngliche Nachricht----- > > > > Von: pyw...@li... > > > > [mailto:pyw...@li...] Im Auftrag > > > > von Javier privat > > > > Gesendet: Mittwoch, 2. August 2006 21:56 > > > > An: D=F6ring, Markus > > > > Cc: PyWrapper Developers mailing list > > > > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper > > > > > > > > In other software I have seen calling it "packages" > > > > > > > > Cheer.s > > > > > > > > On 02/08/2006, at 14:40, D=F6ring, Markus wrote: > > > > > > > > > So lets include a new directory called "installer" in > > the project. > > > > > If we dont like the name we can change it later, but I cant > > > > think of > > > > > any better right now. > > > > > I will add some of the libs already. But remember to > > only use the > > > > > source installers, never the comiled stuff. > > > > > > > > > > -- Markus > > > > > > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > > >> Von: pyw...@li... > > > > >> [mailto:pyw...@li...] Im > > > > Auftrag von > > > > >> D=F6ring, Markus > > > > >> Gesendet: Mittwoch, 2. August 2006 14:31 > > > > >> An: PyWrapper Developers mailing list; Javier privat > > > > >> Betreff: Re: [PyWrapper-devel] Libraries distribution in > > > > >> PyWrapper > > > > >> > > > > >> mx.DateTime alone is also open source. > > > > >> http://www.egenix.com/files/python/mxDateTime.html#Copyright > > > > >> > > > > >> their own kind of license, but I cant see any problem > > > > >> distributing > > > > >> it: > > > > >> http://www.egenix.com/files/python/mxLicense.html#Public > > > > >> > > > > >> > > > > >> -- 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=3Dsourcefo= rge > > > > >> &CID=3DDEVDEV > > > > >>> _______________________________________________ > > > > >>> PyWrapper-devel mailing list > > > > >>> PyW...@li... > > > > >>> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > > > >>> > > > > >> > > > > >> -------------------------------------------------------------- > > > > >> ----------- > > > > >> 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=3Dsourcefor= ge > > > > > &CID=3DDEVDEV > > > > >> _______________________________________________ > > > > >> PyWrapper-devel mailing list > > > > >> PyW...@li... > > > > >> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > > > >> > > > > > > > > > > > > -------------------------------------------------------------- > > > > ----------- > > > > 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 > > > > > > > > > > > > ---------------------------------------------------------------------- > > > --- 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= =3DDEV > > > DEV _______________________________________________ > > > PyWrapper-devel mailing list > > > PyW...@li... > > > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > > > > > > -------------------------------------------------------------- > > ----------- > > 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 > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > |
|
From: <m.d...@BG...> - 2006-08-03 11:26:31
|
theres make and ant. ant is newer and more powerful (I think). the start_server.py script is like the shell script. we can modify it to accept an optional port to run under, defaulting to = 8080 or so. good idea! I still dont know how db_modules will work if they depend on the = installation of the target system. I hope we dont ned to build python for windows ourselves. thats = horrible, it needs the commercial MS Visual C++ compiler. http://uucode.com/texts/python-mingw/python-mingw.html cherrypy is needed for all webapps! but you can run it behind mod_python (maybe thats broken now, but you = should be able to) if you like. BTW, there a doc about embedding python in your application that I = havent read: http://docs.python.org/ext/ext.html -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von Javier privat > Gesendet: Donnerstag, 3. August 2006 12:38 > An: PyWrapper Developers mailing list > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper >=20 > Ok, in Windows is clear, I think we should provide an=20 > installer that installs everything, python and all libraries.=20 > Aditionally will be nice to have a little interface to start=20 > and stop cherrypy server if they want to use it instead of=20 > their existing server. I like it because people can try=20 > things very fast without having to configure anything. >=20 > For Mac I would treat it as Linux, it is enough to have to=20 > take care of two things! I was actually thinking on a=20 > configure file that looks for dependencies of the database=20 > modules and where you can pass as arguments the location of=20 > them. Then something like build that compiles python and all=20 > libraries in our own folder, not touching anything of the=20 > host machine. Me as a user I prefer to not have to touch my=20 > python to install pywrapper, I prefer that everything stays=20 > into one single folder that I can send to the trash when I=20 > want to uninstall. >=20 > And then I would have a script to start cherrypy, like the=20 > start_server.py that we have but that is a shell script and=20 > that I can pass the port where I want the server to run in. >=20 > Correct me, if I am wrong, will the config tool work outside=20 > of cherrypy? >=20 > Cheers. >=20 > PD: What is the difference/advantages of build and ant? >=20 > On 8/3/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > > in java for sure. In python its modules. But I saw in=20 > CheeseShop that they call it packages as well. I will rename=20 > it, good choice! > > > > -- Markus > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: pyw...@li... > > > [mailto:pyw...@li...] Im Auftrag=20 > > > von Javier privat > > > Gesendet: Mittwoch, 2. August 2006 21:56 > > > An: D=F6ring, Markus > > > Cc: PyWrapper Developers mailing list > > > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper > > > > > > In other software I have seen calling it "packages" > > > > > > Cheer.s > > > > > > On 02/08/2006, at 14:40, D=F6ring, Markus wrote: > > > > > > > So lets include a new directory called "installer" in=20 > the project. > > > > If we dont like the name we can change it later, but I cant > > > think of > > > > any better right now. > > > > I will add some of the libs already. But remember to=20 > only use the=20 > > > > source installers, never the comiled stuff. > > > > > > > > -- Markus > > > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > >> Von: pyw...@li... > > > >> [mailto:pyw...@li...] Im > > > Auftrag von > > > >> D=F6ring, Markus > > > >> Gesendet: Mittwoch, 2. August 2006 14:31 > > > >> An: PyWrapper Developers mailing list; Javier privat > > > >> Betreff: Re: [PyWrapper-devel] Libraries distribution in=20 > > > >> PyWrapper > > > >> > > > >> mx.DateTime alone is also open source. > > > >> http://www.egenix.com/files/python/mxDateTime.html#Copyright > > > >> > > > >> their own kind of license, but I cant see any problem=20 > > > >> distributing > > > >> it: > > > >> http://www.egenix.com/files/python/mxLicense.html#Public > > > >> > > > >> > > > >> -- 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=20 > think most=20 > > > >>> of these libraries, I think actually all, can be legally > > > redistributed > > > >>> with other software so I was wondering if we could not embed=20 > > > >>> everything into PyWrapper. > > > >>> > > > >>> Well, I know there are some problems. Some of these > > > >> libraries need to > > > >>> be compiled in unix and therefore installation is=20 > needed. But in=20 > > > >>> 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=20 > install a certain=20 > > > >>> 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=20 > difficult to=20 > > > >>> install in mac os x. Any ideas? > > > >>> > > > >>> Cheers. > > > >>> > > > >>> -------------------------------------------------------------- > > > >>> ----------- > > > >>> Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > > >>> 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 > > > >>> > > > >> > > > >> -------------------------------------------------------------- > > > >> ----------- > > > >> Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > > >> SourceForge.net's Techsay panel and you'll get the chance to=20 > > > >> share your opinions on IT & business topics through=20 > brief surveys=20 > > > >> -- and earn cash=20 > > > >> = 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 > > > >> > > > > > > > > > -------------------------------------------------------------- > > > ----------- > > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > > SourceForge.net's Techsay panel and you'll get the chance=20 > to share=20 > > > your opinions on IT & business topics through brief=20 > surveys -- and=20 > > > earn cash=20 > > > 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 > > > > > > >=20 > ---------------------------------------------------------------------- > > --- Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > SourceForge.net's Techsay panel and you'll get the chance to share=20 > > your opinions on IT & business topics through brief surveys -- and=20 > > earn cash=20 > >=20 > = http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEV > > DEV _______________________________________________ > > PyWrapper-devel mailing list > > PyW...@li... > > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > 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 >=20 |
|
From: Javier de la T. <ja...@gm...> - 2006-08-03 10:38:30
|
Sorry I mean makefiles... On 8/3/06, Javier de la Torre <ja...@gm...> wrote: > Ok, in Windows is clear, I think we should provide an installer that > installs everything, python and all libraries. Aditionally will be > nice to have a little interface to start and stop cherrypy server if > they want to use it instead of their existing server. I like it > because people can try things very fast without having to configure > anything. > > For Mac I would treat it as Linux, it is enough to have to take care > of two things! I was actually thinking on a configure file that looks > for dependencies of the database modules and where you can pass as > arguments the location of them. Then something like build that > compiles python and all libraries in our own folder, not touching > anything of the host machine. Me as a user I prefer to not have to > touch my python to install pywrapper, I prefer that everything stays > into one single folder that I can send to the trash when I want to > uninstall. > > And then I would have a script to start cherrypy, like the > start_server.py that we have but that is a shell script and that I can > pass the port where I want the server to run in. > > Correct me, if I am wrong, will the config tool work outside of cherrypy? > > Cheers. > > PD: What is the difference/advantages of build and ant? > > On 8/3/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > > in java for sure. In python its modules. But I saw in CheeseShop that t= hey call it packages as well. I will rename it, good choice! > > > > -- Markus > > > > > > > -----Urspr=FCngliche Nachricht----- > > > Von: pyw...@li... > > > [mailto:pyw...@li...] Im > > > Auftrag von Javier privat > > > Gesendet: Mittwoch, 2. August 2006 21:56 > > > An: D=F6ring, Markus > > > Cc: PyWrapper Developers mailing list > > > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper > > > > > > In other software I have seen calling it "packages" > > > > > > Cheer.s > > > > > > On 02/08/2006, at 14:40, D=F6ring, Markus wrote: > > > > > > > So lets include a new directory called "installer" in the project. > > > > If we dont like the name we can change it later, but I cant > > > think of > > > > any better right now. > > > > I will add some of the libs already. But remember to only use the > > > > source installers, never the comiled stuff. > > > > > > > > -- Markus > > > > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > > >> Von: pyw...@li... > > > >> [mailto:pyw...@li...] Im > > > Auftrag von > > > >> D=F6ring, Markus > > > >> Gesendet: Mittwoch, 2. August 2006 14:31 > > > >> An: PyWrapper Developers mailing list; Javier privat > > > >> Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper > > > >> > > > >> mx.DateTime alone is also open source. > > > >> http://www.egenix.com/files/python/mxDateTime.html#Copyright > > > >> > > > >> their own kind of license, but I cant see any problem distributing > > > >> it: > > > >> http://www.egenix.com/files/python/mxLicense.html#Public > > > >> > > > >> > > > >> -- 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=3Dsourceforg= e > > > >> &CID=3DDEVDEV > > > >>> _______________________________________________ > > > >>> PyWrapper-devel mailing list > > > >>> PyW...@li... > > > >>> https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > > > >>> > > > >> > > > >> -------------------------------------------------------------- > > > >> ----------- > > > >> 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 > > > >> > > > > > > > > > -------------------------------------------------------------- > > > ----------- > > > 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 > > > > > > > -----------------------------------------------------------------------= -- > > 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 > > > |
|
From: Javier de la T. <ja...@gm...> - 2006-08-03 10:37:41
|
Ok, in Windows is clear, I think we should provide an installer that installs everything, python and all libraries. Aditionally will be nice to have a little interface to start and stop cherrypy server if they want to use it instead of their existing server. I like it because people can try things very fast without having to configure anything. For Mac I would treat it as Linux, it is enough to have to take care of two things! I was actually thinking on a configure file that looks for dependencies of the database modules and where you can pass as arguments the location of them. Then something like build that compiles python and all libraries in our own folder, not touching anything of the host machine. Me as a user I prefer to not have to touch my python to install pywrapper, I prefer that everything stays into one single folder that I can send to the trash when I want to uninstall. And then I would have a script to start cherrypy, like the start_server.py that we have but that is a shell script and that I can pass the port where I want the server to run in. Correct me, if I am wrong, will the config tool work outside of cherrypy? Cheers. PD: What is the difference/advantages of build and ant? On 8/3/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > in java for sure. In python its modules. But I saw in CheeseShop that the= y call it packages as well. I will rename it, good choice! > > -- Markus > > > > -----Urspr=FCngliche Nachricht----- > > Von: pyw...@li... > > [mailto:pyw...@li...] Im > > Auftrag von Javier privat > > Gesendet: Mittwoch, 2. August 2006 21:56 > > An: D=F6ring, Markus > > Cc: PyWrapper Developers mailing list > > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper > > > > In other software I have seen calling it "packages" > > > > Cheer.s > > > > On 02/08/2006, at 14:40, D=F6ring, Markus wrote: > > > > > So lets include a new directory called "installer" in the project. > > > If we dont like the name we can change it later, but I cant > > think of > > > any better right now. > > > I will add some of the libs already. But remember to only use the > > > source installers, never the comiled stuff. > > > > > > -- Markus > > > > > > > > >> -----Urspr=FCngliche Nachricht----- > > >> Von: pyw...@li... > > >> [mailto:pyw...@li...] Im > > Auftrag von > > >> D=F6ring, Markus > > >> Gesendet: Mittwoch, 2. August 2006 14:31 > > >> An: PyWrapper Developers mailing list; Javier privat > > >> Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper > > >> > > >> mx.DateTime alone is also open source. > > >> http://www.egenix.com/files/python/mxDateTime.html#Copyright > > >> > > >> their own kind of license, but I cant see any problem distributing > > >> it: > > >> http://www.egenix.com/files/python/mxLicense.html#Public > > >> > > >> > > >> -- 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 > > >>> > > >> > > >> -------------------------------------------------------------- > > >> ----------- > > >> 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 > > >> > > > > > > -------------------------------------------------------------- > > ----------- > > 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 > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > |
|
From: <m.d...@BG...> - 2006-08-03 08:44:12
|
in java for sure. In python its modules. But I saw in CheeseShop that = they call it packages as well. I will rename it, good choice! -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von Javier privat > Gesendet: Mittwoch, 2. August 2006 21:56 > An: D=F6ring, Markus > Cc: PyWrapper Developers mailing list > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper >=20 > In other software I have seen calling it "packages" >=20 > Cheer.s >=20 > On 02/08/2006, at 14:40, D=F6ring, Markus wrote: >=20 > > So lets include a new directory called "installer" in the project. > > If we dont like the name we can change it later, but I cant=20 > think of=20 > > any better right now. > > I will add some of the libs already. But remember to only use the=20 > > source installers, never the comiled stuff. > > > > -- Markus > > > > > >> -----Urspr=FCngliche Nachricht----- > >> Von: pyw...@li... > >> [mailto:pyw...@li...] Im=20 > Auftrag von=20 > >> D=F6ring, Markus > >> Gesendet: Mittwoch, 2. August 2006 14:31 > >> An: PyWrapper Developers mailing list; Javier privat > >> Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper > >> > >> mx.DateTime alone is also open source. > >> http://www.egenix.com/files/python/mxDateTime.html#Copyright > >> > >> their own kind of license, but I cant see any problem distributing > >> it: > >> http://www.egenix.com/files/python/mxLicense.html#Public > >> > >> > >> -- 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=20 > deploying=20 > >>> 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=20 > >>> these libraries, I think actually all, can be legally=20 > redistributed=20 > >>> with other software so I was wondering if we could not embed=20 > >>> 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=20 > >>> 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=20 > >>> 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=20 > >>> install in mac os x. Any ideas? > >>> > >>> Cheers. > >>> > >>> -------------------------------------------------------------- > >>> ----------- > >>> Take Surveys. Earn Cash. Influence the Future of IT Join=20 > >>> SourceForge.net's Techsay panel and you'll get the chance=20 > to share=20 > >>> your opinions on IT & business topics through brief=20 > surveys -- and=20 > >>> earn cash=20 > >>> 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 > >>> > >> > >> -------------------------------------------------------------- > >> ----------- > >> Take Surveys. Earn Cash. Influence the Future of IT Join=20 > >> SourceForge.net's Techsay panel and you'll get the chance to share=20 > >> your opinions on IT & business topics through brief surveys -- and=20 > >> earn cash=20 > >> 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 > >> >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > 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 >=20 |
|
From: <m.d...@BG...> - 2006-08-03 08:08:40
|
right. but you cant ask the users to compile a python interpreter. So only for = Windows and OSX you would be able to include a compiled python. Sure = thats possible, but a bit of work I guess. There are tools to convert python scripts into OS native code, like = py2app for OSX: http://undefined.org/python/py2app.html A large problem I see is that we cannot include all db drivers into the = package. Oracle for example needs the Oracle client libs on the system = and during compilation they hardcode paths. I think even mysql and = postgres fix the path to the mysql binaries and configurations during = compilation. So we would definitely need a bundle where you can still = access parts and add you own libs - maybe in another directory though. So for linux I think the way it is is good. For OSX its on the edge cause py23 is included, but we will need py24. For windows its ok, but a full installation would make life easier for = them. We surely will need ANT then to get control over all the different = builds we need. If you want go ahead and play with the idea. Maybe for pywrapper2.4? 1 build for WIN, 1 for OSX.4 and like it is for linux? -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von Javier privat > Gesendet: Mittwoch, 2. August 2006 19:04 > An: PyWrapper Developers mailing list > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper >=20 > On 8/2/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > > guessed right. > > its becoming like the gbif super-all-inclusive-installer then. > > which noone uses because you cant adapt it to your system. >=20 > Come on!! It is not the same! We are not asking people to=20 > install a webserver (actually you do jeje). People dont mind=20 > if we use our own python or with theirs! There is no port=20 > being used because of installing another python where they=20 > dont even see it... >=20 > This reminds me a little bit the discussion of including the=20 > Java virtual machine embeded in Java desktop applications.=20 > Most of the people start saying that they dont want to see=20 > that!! and after some time fighting with user problems=20 > because incopatibilities, people installing libraries where=20 > they should not, etc they pray to see the virtual machine=20 > embeded so that they can control it!!! >=20 > I see the same hapenning with us... and you will see the=20 > troubles we are gonna have with people with old biocase=20 > providers installed, with old libraries, old pythons... aghh=20 > I am suffering already... if we could control everything and=20 > update everything we need that will be great... >=20 > Cheers. >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > 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 >=20 |
|
From: Javier de la T. <ja...@gm...> - 2006-08-02 19:56:35
|
In other software I have seen calling it "packages" Cheer.s On 02/08/2006, at 14:40, D=F6ring, Markus wrote: > So lets include a new directory called "installer" in the project. > If we dont like the name we can change it later, but I cant think =20 > of any better right now. > I will add some of the libs already. But remember to only use the =20 > source installers, never the comiled stuff. > > -- Markus > > >> -----Urspr=FCngliche Nachricht----- >> Von: pyw...@li... >> [mailto:pyw...@li...] Im >> Auftrag von D=F6ring, Markus >> Gesendet: Mittwoch, 2. August 2006 14:31 >> An: PyWrapper Developers mailing list; Javier privat >> Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper >> >> mx.DateTime alone is also open source. >> http://www.egenix.com/files/python/mxDateTime.html#Copyright >> >> their own kind of license, but I cant see any problem distributing =20= >> it: >> http://www.egenix.com/files/python/mxLicense.html#Public >> >> >> -- 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 >>> >> >> -------------------------------------------------------------- >> ----------- >> 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 >> |
|
From: Javier de la T. <ja...@gm...> - 2006-08-02 17:05:44
|
Ah!! And what do you think that people want to adapt in their python installations to run PyWrapper???!! Come on!! Is not the same as installing an Apache! Cheers. On 8/2/06, Javier de la Torre <ja...@gm...> wrote: > On 8/2/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > > guessed right. > > its becoming like the gbif super-all-inclusive-installer then. > > which noone uses because you cant adapt it to your system. > > Come on!! It is not the same! We are not asking people to install a > webserver (actually you do jeje). People dont mind if we use our own > python or with theirs! There is no port being used because of > installing another python where they dont even see it... > > This reminds me a little bit the discussion of including the Java > virtual machine embeded in Java desktop applications. Most of the > people start saying that they dont want to see that!! and after some > time fighting with user problems because incopatibilities, people > installing libraries where they should not, etc they pray to see the > virtual machine embeded so that they can control it!!! > > I see the same hapenning with us... and you will see the troubles we > are gonna have with people with old biocase providers installed, with > old libraries, old pythons... aghh I am suffering already... if we > could control everything and update everything we need that will be > great... > > Cheers. > |
|
From: Javier de la T. <ja...@gm...> - 2006-08-02 17:04:22
|
On 8/2/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > guessed right. > its becoming like the gbif super-all-inclusive-installer then. > which noone uses because you cant adapt it to your system. Come on!! It is not the same! We are not asking people to install a webserver (actually you do jeje). People dont mind if we use our own python or with theirs! There is no port being used because of installing another python where they dont even see it... This reminds me a little bit the discussion of including the Java virtual machine embeded in Java desktop applications. Most of the people start saying that they dont want to see that!! and after some time fighting with user problems because incopatibilities, people installing libraries where they should not, etc they pray to see the virtual machine embeded so that they can control it!!! I see the same hapenning with us... and you will see the troubles we are gonna have with people with old biocase providers installed, with old libraries, old pythons... aghh I am suffering already... if we could control everything and update everything we need that will be great... Cheers. |
|
From: <m.d...@BG...> - 2006-08-02 12:40:18
|
So lets include a new directory called "installer" in the project. If we dont like the name we can change it later, but I cant think of any = better right now. I will add some of the libs already. But remember to only use the source = installers, never the comiled stuff. -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von D=F6ring, Markus > Gesendet: Mittwoch, 2. August 2006 14:31 > An: PyWrapper Developers mailing list; Javier privat > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper >=20 > mx.DateTime alone is also open source. > http://www.egenix.com/files/python/mxDateTime.html#Copyright >=20 > their own kind of license, but I cant see any problem distributing it: > http://www.egenix.com/files/python/mxLicense.html#Public >=20 >=20 > -- Markus > =20 >=20 > > -----Urspr=FCngliche Nachricht----- > > Von: pyw...@li... > > [mailto:pyw...@li...] Im=20 > Auftrag von=20 > > Javier privat > > Gesendet: Mittwoch, 2. August 2006 12:24 > > An: PyWrapper Developers mailing list > > Betreff: [PyWrapper-devel] Libraries distribution in PyWrapper > >=20 > > Hi, > >=20 > > I was wondering if we could change a bit our strategy for deploying=20 > > PyWrapper. Right now to install it you have to install: > >=20 > > 1)PyXML > > 2)mxDateTime > > 3)CherryPy > > 4)elementtree > > 5)kid > >=20 > > Then you probably will also need: > >=20 > > 6) libxml2 > > 7) a database module > >=20 > > and finally if you want BioMOBY support now I will also be=20 > requiring: > >=20 > > 8) fpconst > > 9) SOAPpy > > 10) BioMOBY Python > >=20 > > This is getting a little bit horrible to install. I think most of=20 > > these libraries, I think actually all, can be legally redistributed=20 > > with other software so I was wondering if we could not embed=20 > > everything into PyWrapper. > >=20 > > Well, I know there are some problems. Some of these=20 > libraries need to=20 > > be compiled in unix and therefore installation is needed. But in=20 > > Windows we might be able to distribute them already=20 > compiled. In the=20 > > case of unix we can at least include them in the package=20 > and provide=20 > > an installer that install all of them into our external_lib=20 > directory. > >=20 > > We can have something like /lib/external_lib folder where=20 > we include=20 > > all this stuff. Do you know what happens if we install a certain=20 > > version of a library there and the user has already the=20 > same library=20 > > installed on his python? Which one will take preference? > >=20 > > And there is still the open issue of which library to use=20 > for xslt... > > we are not happy with none of them and they are all difficult to=20 > > install in mac os x. Any ideas? > >=20 > > Cheers. > >=20 > > -------------------------------------------------------------- > > ----------- > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > SourceForge.net's Techsay panel and you'll get the chance to share=20 > > your opinions on IT & business topics through brief surveys -- and=20 > > earn cash=20 > > 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 > >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > 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 >=20 |
|
From: <m.d...@BG...> - 2006-08-02 12:31:04
|
mx.DateTime alone is also open source. http://www.egenix.com/files/python/mxDateTime.html#Copyright their own kind of license, but I cant see any problem distributing it: http://www.egenix.com/files/python/mxLicense.html#Public -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von Javier privat > Gesendet: Mittwoch, 2. August 2006 12:24 > An: PyWrapper Developers mailing list > Betreff: [PyWrapper-devel] Libraries distribution in PyWrapper >=20 > Hi, >=20 > I was wondering if we could change a bit our strategy for=20 > deploying PyWrapper. Right now to install it you have to install: >=20 > 1)PyXML > 2)mxDateTime > 3)CherryPy > 4)elementtree > 5)kid >=20 > Then you probably will also need: >=20 > 6) libxml2 > 7) a database module >=20 > and finally if you want BioMOBY support now I will also be requiring: >=20 > 8) fpconst > 9) SOAPpy > 10) BioMOBY Python >=20 > This is getting a little bit horrible to install. I think=20 > most of these libraries, I think actually all, can be legally=20 > redistributed with other software so I was wondering if we=20 > could not embed everything into PyWrapper. >=20 > Well, I know there are some problems. Some of these libraries=20 > need to be compiled in unix and therefore installation is=20 > needed. But in Windows we might be able to distribute them=20 > already compiled. In the case of unix we can at least include=20 > them in the package and provide an installer that install all=20 > of them into our external_lib directory. >=20 > We can have something like /lib/external_lib folder where we=20 > include all this stuff. Do you know what happens if we=20 > install a certain version of a library there and the user has=20 > already the same library installed on his python? Which one=20 > will take preference? >=20 > 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=20 > to install in mac os x. Any ideas? >=20 > Cheers. >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > 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 >=20 |
|
From: <m.d...@BG...> - 2006-08-02 12:27:04
|
guessed right. its becoming like the gbif super-all-inclusive-installer then.=20 which noone uses because you cant adapt it to your system. -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von Javier privat > Gesendet: Mittwoch, 2. August 2006 13:16 > An: D=F6ring, Markus > Cc: PyWrapper Developers mailing list > Betreff: Re: [PyWrapper-devel] Libraries distribution in PyWrapper >=20 > Yes, it works for me... >=20 > SOAPpy and biomoby are pure Python so we can bundle. >=20 > I think mxDateTime as you said is fine... the proble is if=20 > you use the odbc stuff if I remember... so this one can not=20 > even be distributed, it MUST be downloaded from their site...=20 > apart of this I think we can include all of them in PyWrapper=20 > and create an installer scripts that does the work for the user... >=20 > With this I will be satisfied... also we will have much more=20 > control over the libraries versions... >=20 > And now an even more dramatic suggestion... what about=20 > including Python itself also? So in Windows in easy, you just=20 > have to run the installer (PyWrapper) and everything,=20 > including Pthon is installed for you in a folder, we dont=20 > touch anything. > In Unix we can create an installer that installs python and=20 > all requiered libraries under our folder... >=20 > I know it is not the most common way of distributing=20 > applications, but if this is gonna get deploy in so many=20 > places this looks like it will save us some headaches... >=20 > Now Markus I know will not like the idea :D >=20 > Cheers. >=20 > 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.=20 > Everything under lib which is not biocase/ is external stuff. > > So we should go through the required libs and if they do=20 > not need to be compiled, so if they are pure python, we can=20 > simply add them to our lib folder! > > > > 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=20 > system, we might get into trouble. > > But if we make sure (which I think is the case already!)=20 > that our lib path comes before the regular system lib path in=20 > 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',=20 > > '/home/biocase/tapir/webapp', '/usr/lib/python24.zip',=20 > > '/usr/lib/python2.4', '/usr/lib/python2.4/plat-linux2',=20 > > '/usr/lib/python2.4/lib-tk', '/usr/lib/python2.4/lib-dynload',=20 > > '/usr/local/lib/python2.4/site-packages',=20 > > '/usr/lib/python2.4/site-packages',=20 > > '/usr/lib/python2.4/site-packages/setuptools-0.6a7-py2.4.egg',=20 > > '/usr/lib/python2.4/site-packages/kid-0.9-py2.4.egg',=20 > > '/usr/lib/python2.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=20 > dont have to go and look for the right version. > > > > > > With mx.DateTime we need to get in touch with eGenix. I=20 > know they dont like the idea in general (they've been=20 > contacting me during biocase times). But if we dont use the=20 > entire mxEgenixBase package, but only mxDateTime, they might=20 > 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=20 > > > 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=20 > deploying=20 > > > 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=20 > be requiring: > > > > > > 8) fpconst > > > 9) SOAPpy > > > 10) BioMOBY Python > > > > > > This is getting a little bit horrible to install. I think most of=20 > > > these libraries, I think actually all, can be legally=20 > redistributed=20 > > > with other software so I was wondering if we could not embed=20 > > > everything into PyWrapper. > > > > > > Well, I know there are some problems. Some of these=20 > libraries need=20 > > > to be compiled in unix and therefore installation is=20 > needed. But in=20 > > > Windows we might be able to distribute them already=20 > compiled. In the=20 > > > case of unix we can at least include them in the package=20 > and provide=20 > > > an installer that install all of them into our external_lib=20 > > > directory. > > > > > > We can have something like /lib/external_lib folder where=20 > we include=20 > > > all this stuff. Do you know what happens if we install a certain=20 > > > version of a library there and the user has already the=20 > same library=20 > > > installed on his python? Which one will take preference? > > > > > > And there is still the open issue of which library to use=20 > for xslt... > > > we are not happy with none of them and they are all difficult to=20 > > > install in mac os x. Any ideas? > > > > > > Cheers. > > > > > > -------------------------------------------------------------- > > > ----------- > > > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > > > SourceForge.net's Techsay panel and you'll get the chance=20 > to share=20 > > > your opinions on IT & business topics through brief=20 > surveys -- and=20 > > > earn cash=20 > > > 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 > > > > > >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > 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 >=20 |
|
From: Javier de la T. <ja...@gm...> - 2006-08-02 11:16:32
|
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 > > > |
|
From: <m.d...@BG...> - 2006-08-02 11:08:32
|
Javi, you are perfectly right. its getting horrible. Actually Ive already bundled a library with pywrapper. Everything under = lib which is not biocase/ is external stuff. So we should go through the required libs and if they do not need to be = compiled, so if they are pure python, we can simply add them to our lib = folder! But=20 > 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 = get into trouble. But if we make sure (which I think is the case already!) that our lib = path 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/python2.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/python2.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 = go and look for the right version. With mx.DateTime we need to get in touch with eGenix. I know they dont = like the idea in general (they've been contacting me during biocase = times). But if we dont use the entire mxEgenixBase package, but only = mxDateTime, they might be OK. it comes with linux distributions anyways. Does this work for you? -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von Javier privat > Gesendet: Mittwoch, 2. August 2006 12:24 > An: PyWrapper Developers mailing list > Betreff: [PyWrapper-devel] Libraries distribution in PyWrapper >=20 > Hi, >=20 > I was wondering if we could change a bit our strategy for=20 > deploying PyWrapper. Right now to install it you have to install: >=20 > 1)PyXML > 2)mxDateTime > 3)CherryPy > 4)elementtree > 5)kid >=20 > Then you probably will also need: >=20 > 6) libxml2 > 7) a database module >=20 > and finally if you want BioMOBY support now I will also be requiring: >=20 > 8) fpconst > 9) SOAPpy > 10) BioMOBY Python >=20 > This is getting a little bit horrible to install. I think=20 > most of these libraries, I think actually all, can be legally=20 > redistributed with other software so I was wondering if we=20 > could not embed everything into PyWrapper. >=20 > Well, I know there are some problems. Some of these libraries=20 > need to be compiled in unix and therefore installation is=20 > needed. But in Windows we might be able to distribute them=20 > already compiled. In the case of unix we can at least include=20 > them in the package and provide an installer that install all=20 > of them into our external_lib directory. >=20 > We can have something like /lib/external_lib folder where we=20 > include all this stuff. Do you know what happens if we=20 > install a certain version of a library there and the user has=20 > already the same library installed on his python? Which one=20 > will take preference? >=20 > 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=20 > to install in mac os x. Any ideas? >=20 > Cheers. >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > 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 >=20 |
|
From: Javier de la T. <ja...@gm...> - 2006-08-02 10:24:08
|
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. |
|
From: Javier de la T. <ja...@gm...> - 2006-07-31 13:18:31
|
Cool, Then we dont have to discuss anything. Lets make it optional. Cheers. On 7/31/06, "D=F6ring, Markus" <m.d...@bg...> wrote: > good. > PyWrapper caches the metadata in a file and the provider can specify how = often it should be updated. Usually once a day. Then its lightning fast exc= ept for the 1 query. But an empty metadata element is ok. The schema curren= tly doesnt allow this I think. Should we make at least the dct:modified opt= ional? Ah, the ABCDdiscussion again... > > -- Markus > > > > -----Urspr=FCngliche Nachricht----- > > Von: pyw...@li... > > [mailto:pyw...@li...] Im > > Auftrag von Renato De Giovanni > > Gesendet: Montag, 31. Juli 2006 14:28 > > An: tdw...@li... > > Cc: PyWrapper Developers mailing list > > Betreff: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir: > > capabilities > > > > OK, Markus. Agreed. > > But maybe we could also consider an empty metadata response, > > because "dct:modified" will likely require interaction with > > the DB. And it could take some time for the larger ones > > (experience from DiGIR). > > > > Regards, > > -- > > Renato > > > > > I have implemented the log-only request now and would like > > to suggest > > > the > > > following: > > > > > > 1) add "log-only" attribute to responeOperationGroup. Ive chosen > > > "log-only" cause we already have there an attribute "apply-xslt" > > > 2) add a mandatory boolean attribute "logRequestsDenied" to the > > > operation element in a capabilities request > > > 3) use existing responses for the log-only request. So if you do a > > > search with log-only active, you will get an empty search response > > > back. Thats much easier to implement and doesnt require any > > change in > > > the schema. The same works with inventories. Pong, Capa & Meta > > > responses dont cost much anyway, so we could do a normal > > response (if > > > anyway uses log-only with those requests at all) > > > > > > > > > Does everyone agree to this? > > > The schema is already updated for this. > > > > > > > > > Markus > > > > > > > > -------------------------------------------------------------- > > ----------- > > 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 > > > > ------------------------------------------------------------------------- > Take Surveys. Earn Cash. Influence the Future of IT > Join SourceForge.net's Techsay panel and you'll get the chance to share y= our > opinions on IT & business topics through brief surveys -- and earn cash > http://www.techsay.com/default.php?page=3Djoin.php&p=3Dsourceforge&CID=3D= DEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > |
|
From: <m.d...@BG...> - 2006-07-31 13:16:14
|
good.=20 PyWrapper caches the metadata in a file and the provider can specify how = often it should be updated. Usually once a day. Then its lightning fast = except for the 1 query. But an empty metadata element is ok. The schema = currently doesnt allow this I think. Should we make at least the = dct:modified optional? Ah, the ABCDdiscussion again... -- Markus =20 > -----Urspr=FCngliche Nachricht----- > Von: pyw...@li...=20 > [mailto:pyw...@li...] Im=20 > Auftrag von Renato De Giovanni > Gesendet: Montag, 31. Juli 2006 14:28 > An: tdw...@li... > Cc: PyWrapper Developers mailing list > Betreff: Re: [PyWrapper-devel] [tdwg-tapir] RE: WG: tapir:=20 > capabilities >=20 > OK, Markus. Agreed. > But maybe we could also consider an empty metadata response,=20 > because "dct:modified" will likely require interaction with=20 > the DB. And it could take some time for the larger ones=20 > (experience from DiGIR). >=20 > Regards, > -- > Renato >=20 > > I have implemented the log-only request now and would like=20 > to suggest=20 > > the > > following: > > > > 1) add "log-only" attribute to responeOperationGroup. Ive chosen=20 > > "log-only" cause we already have there an attribute "apply-xslt" > > 2) add a mandatory boolean attribute "logRequestsDenied" to the=20 > > operation element in a capabilities request > > 3) use existing responses for the log-only request. So if you do a=20 > > search with log-only active, you will get an empty search response=20 > > back. Thats much easier to implement and doesnt require any=20 > change in=20 > > the schema. The same works with inventories. Pong, Capa & Meta=20 > > responses dont cost much anyway, so we could do a normal=20 > response (if=20 > > anyway uses log-only with those requests at all) > > > > > > Does everyone agree to this? > > The schema is already updated for this. > > > > > > Markus >=20 >=20 >=20 > -------------------------------------------------------------- > ----------- > Take Surveys. Earn Cash. Influence the Future of IT Join=20 > SourceForge.net's Techsay panel and you'll get the chance to=20 > share your opinions on IT & business topics through brief=20 > surveys -- and earn cash=20 > 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 >=20 |
|
From: Javier de la T. <ja...@gm...> - 2006-07-31 12:47:15
|
Right right... I checked also implementations on Python and I couldnt find... As you said doing a much simpler tool that just read and produce this xml is much simpler... I managed to configure the PHP stuff you gave me in Tervuren, but did not have time to work on changing it for DHTML. I will then use very simple python to generate the XML and write in the file... Javi. On 7/31/06, Renato De Giovanni <re...@cr...> wrote: > Hi Javi, > > We already talked about this last week, but I think it's interesting to > leave a message in the mailing list as well. > > Dave Thau tried the same approach (XForms) some years ago when he was > developing the configurator for the PHP provider. You can still find his > code in the DiGIR CVS repository on sourceforge. It's Java, I think. But > at that time I remember he said that the tools were not ready for XForms, > and so the PHP provider ended up with the web configurator that I was > developing simultaneously. > > I'm not sure what's the current status of XForms libraries (maybe they are > ready?). So if there's something for Python, maybe you could try. > > The web configurator that I developed for the PHP provider makes use of > similar XForms functionalities - it builds the metadata form based on a > piece of XML Schema. However, I must say that during all these years the > DiGIR metadata NEVER changed. So a much simpler piece of PHP code would > have done the job more quickly and easily. And personally I think the > TAPIR metadata is really nice, so I wouldn't be surprised if it also keeps > unchanged for many years. > > Another thing to note is that any XForms library that you may decide to > use will need to be able to handle xsd:imports mixing elements from > different namespaces & XML Schemas, since TAPIR uses DublinCore, VCard, > GeoPoint, etc... > > Regards, > -- > Renato > > > > Hi, > > > > Actually there is no editor for the metadata in the PyWrapper > > configuration tool. The metadata is stored in an XML document > > comformant to the TAPIR XML schema. > > > > It looks like the perfect scenario to try XForms. We read the XML > > schema to generate the HTML with the form to edit and then we > > serialize with XUpdate to update the XML document... > > > > In a perfect world this would be automatically done and we would not > > have to program anything, but... anybody has tried something like > > this? > > > > Here is a list of XForms implementations: > > http://www.w3.org/MarkUp/Forms/#implementations > > > > And here are two funny projects that I dont think we can consider but > > that I find curious. > > > > http://bitfluxeditor.org/demo/ > > http://xopus.com/demo/ > > > > 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=join.php&p=sourceforge&CID=DEVDEV > _______________________________________________ > PyWrapper-devel mailing list > PyW...@li... > https://lists.sourceforge.net/lists/listinfo/pywrapper-devel > |
|
From: Renato De G. <re...@cr...> - 2006-07-31 12:43:03
|
Hi Javi, We already talked about this last week, but I think it's interesting to leave a message in the mailing list as well. Dave Thau tried the same approach (XForms) some years ago when he was developing the configurator for the PHP provider. You can still find his code in the DiGIR CVS repository on sourceforge. It's Java, I think. But at that time I remember he said that the tools were not ready for XForms, and so the PHP provider ended up with the web configurator that I was developing simultaneously. I'm not sure what's the current status of XForms libraries (maybe they are ready?). So if there's something for Python, maybe you could try. The web configurator that I developed for the PHP provider makes use of similar XForms functionalities - it builds the metadata form based on a piece of XML Schema. However, I must say that during all these years the DiGIR metadata NEVER changed. So a much simpler piece of PHP code would have done the job more quickly and easily. And personally I think the TAPIR metadata is really nice, so I wouldn't be surprised if it also keeps unchanged for many years. Another thing to note is that any XForms library that you may decide to use will need to be able to handle xsd:imports mixing elements from different namespaces & XML Schemas, since TAPIR uses DublinCore, VCard, GeoPoint, etc... Regards, -- Renato > Hi, > > Actually there is no editor for the metadata in the PyWrapper > configuration tool. The metadata is stored in an XML document > comformant to the TAPIR XML schema. > > It looks like the perfect scenario to try XForms. We read the XML > schema to generate the HTML with the form to edit and then we > serialize with XUpdate to update the XML document... > > In a perfect world this would be automatically done and we would not > have to program anything, but... anybody has tried something like > this? > > Here is a list of XForms implementations: > http://www.w3.org/MarkUp/Forms/#implementations > > And here are two funny projects that I dont think we can consider but > that I find curious. > > http://bitfluxeditor.org/demo/ > http://xopus.com/demo/ > > Cheers. |
|
From: Renato De G. <re...@cr...> - 2006-07-31 12:28:31
|
OK, Markus. Agreed. But maybe we could also consider an empty metadata response, because "dct:modified" will likely require interaction with the DB. And it could take some time for the larger ones (experience from DiGIR). Regards, -- Renato > I have implemented the log-only request now and would like to suggest the > following: > > 1) add "log-only" attribute to responeOperationGroup. Ive chosen > "log-only" cause we already have there an attribute "apply-xslt" > 2) add a mandatory boolean attribute "logRequestsDenied" to the operation > element in a capabilities request > 3) use existing responses for the log-only request. So if you do a search > with log-only active, you will get an empty search response back. Thats > much easier to implement and doesnt require any change in the schema. The > same works with inventories. Pong, Capa & Meta responses dont cost much > anyway, so we could do a normal response (if anyway uses log-only with > those requests at all) > > > Does everyone agree to this? > The schema is already updated for this. > > > Markus |
|
From: <m.d...@BG...> - 2006-07-31 09:38:38
|
We have created a user called "pywrapper" as a substitute for an = anonymous user (which had to be blocked because of spamming).=20 Please login as user pywrapper to submit new tickets: user=3Dpywrapper=20 password=3Dpywrapper This user does not have any rights on the SVN repository. Markus >>> From: pyw...@li... >> on behalf of >>> Javier privat >>> Sent: Sat 7/29/2006 12:38 PM >>> To: PyWrapper Developers mailing list >>> Cc:=09 >>> Subject: [PyWrapper-devel] Close create tickets for >> anonymous users >>> in trac >>> >>> Hi, >>> >>> I had to remove the permission for anonymous users to create new=20 >>> tickets on the Trac system. We started receiving spam last >> week and I >>> suppose that once discovered things can only get worst. >>> >>> I haven't seen any ticket submission from anybody apart of >> Markus and >>> me, but I would like to ask people who is starting to try PyWrapper=20 >>> to contact us and we can create them an account to submit bugs and=20 >>> feature request to the system. >>> >>> Unfortunately it is not possible to self-register. >>> >>> Cheers. >>> >>> Javi. >>> |
|
From: Javier de la T. <ja...@gm...> - 2006-07-29 10:41:05
|
Hi, I had to remove the permission for anonymous users to create new tickets on the Trac system. We started receiving spam last week and I suppose that once discovered things can only get worst. I haven't seen any ticket submission from anybody apart of Markus and me, but I would like to ask people who is starting to try PyWrapper to contact us and we can create them an account to submit bugs and feature request to the system. Unfortunately it is not possible to self-register. Cheers. Javi. |
|
From: Javier de la T. <ja...@gm...> - 2006-07-27 21:16:20
|
Well, being an enumeration you can do a search based on an OR... Normally in enumerations you choose what you want by poiting directly to it, not using LIKE stuff... J. On 7/27/06, Markus D=F6ring <wi...@go...> wrote: > you might want to get all "XXXSpecimen" as opposed to "XXXObservation" yo= u > could do LIKE '*Specimen' > well, but its not needed for living. in PyWrapper this will be an error. > sorry. > M > > > On 7/27/06, Javier de la Torre <ja...@gm...> wrote: > > Is there any sense for doing a like in an enumeration? > > > > I think equals is more than enough and probably more correct. > > > > Javi. > > > > On 7/27/06, Markus D=F6ring <wi...@go... > wrote: > > > hi, > > > id like to implement searching on schema enumerations. > > > I allow to setup a translation between local database terms and > > > schema/concept terms. > > > So when searching I need to translate the argument as well. Thats > horrible > > > for LIKEs. So I will only allow an equal operation for now on > enumerations. > > > Do you think this is very bad? > > > > > > Markus > > > > > > > > > > |
7 messages has been excluded from this view by a project administrator.
