Thread: Re: [SQLObject] a beginning database
SQLObject is a Python ORM.
Brought to you by:
ianbicking,
phd
From: Donnal W. <don...@ya...> - 2005-08-30 16:46:32
|
--- Ian Bicking <ia...@co...> wrote: [snip] > SQLite sounds like the right choice for you. Ok, thanks. So I installed SQLObject 0.6.1 (Windows XP, Python 2.4) and pysqlite 2.0.3 for Python 2.4. My site-packages folder now has the packages 'sqlite' and 'pysqlite2'. The latter has a 316 KB file named '_sqlite.pyd', so I should not need to install SQLite separately, correct? It also contains the module dbapi2.py. But I can't find where sqlbject.sqlite.sqliteconnection ever imports this package/module. I tried renaming the 'pysqlite2' package to 'sqlite', but that didn't help. I know I am missing something simple, but I can't quite put my finger on it. ##======= test code from sqlobject import * import sys, os db_filename = os.path.abspath('mydata.db') if os.path.exists(db_filename): os.unlink(db_filename) # had to add '/' from the example in online introduction connection_string = 'sqlite:' + '/' + db_filename connection = connectionForURI(connection_string) sqlhub.processConnection = connection ======= traceback Traceback (most recent call last): File "C:\Python24\Lib\site-packages\mindwrapper\tryout\try.py", line 8, in ? connection = connectionForURI(connection_string) File "C:\Python24\Lib\site-packages\sqlobject\dbconnection.py", line 658, in connectionForURI conn = self.schemeBuilders[scheme]().connectionFromURI(uri) File "C:\Python24\Lib\site-packages\sqlobject\sqlite\sqliteconnection.py", line 28, in connectionFromURI return cls(filename=path, **args) File "C:\Python24\Lib\site-packages\sqlobject\sqlite\sqliteconnection.py", line 21, in __init__ self._conn = sqlite.connect(self.filename) AttributeError: 'module' object has no attribute 'connect' Exception exceptions.AttributeError: "SQLiteConnection instance has no attribute '_pool'" in <bound method SQLiteConnection.__del__ of <sqlobject.sqlite.sqliteconnection.SQLiteConnection instance at 0x00B18878>> ignored Thanks, Donnal Walter Arkansas Children's Hospital |
From: Donnal W. <don...@ya...> - 2005-08-30 16:53:32
|
--- Donnal Walter <don...@ya...> wrote: > Ok, thanks. So I installed SQLObject 0.6.1 (Windows XP, Python > 2.4) and pysqlite 2.0.3 for Python 2.4. My site-packages folder > now has the packages 'sqlite' and 'pysqlite2'. The latter has a > 316 KB file named '_sqlite.pyd', so I should not need to install > SQLite separately, correct? It also contains the module > dbapi2.py. Oops, I meant to say that my site-packages folder has the packages named 'sqlobject' and 'pysqlite2'. > But I can't find where sqlbject.sqlite.sqliteconnection ... ^^^^^^^^ sqlobject.sqlite.sqliteconnection > ever imports this package/module. I tried renaming the > 'pysqlite2' package to 'sqlite', but that didn't help. I know > I am missing something simple, but I can't quite put my finger > on it. > > ##======= test code > from sqlobject import * > import sys, os > > db_filename = os.path.abspath('mydata.db') > if os.path.exists(db_filename): > os.unlink(db_filename) > > # had to add '/' from the example in online introduction > connection_string = 'sqlite:' + '/' + db_filename > > connection = connectionForURI(connection_string) > sqlhub.processConnection = connection > > ======= traceback > Traceback (most recent call last): > File "C:\Python24\Lib\site-packages\mindwrapper\tryout\try.py", > line 8, in ? > connection = connectionForURI(connection_string) > File "C:\Python24\Lib\site-packages\sqlobject\dbconnection.py", > line 658, in connectionForURI > conn = self.schemeBuilders[scheme]().connectionFromURI(uri) > File > "C:\Python24\Lib\site-packages\sqlobject\sqlite\sqliteconnection.py", > line 28, in connectionFromURI > return cls(filename=path, **args) > File > "C:\Python24\Lib\site-packages\sqlobject\sqlite\sqliteconnection.py", > line 21, in __init__ > self._conn = sqlite.connect(self.filename) > AttributeError: 'module' object has no attribute 'connect' > Exception exceptions.AttributeError: "SQLiteConnection instance > has > no attribute '_pool'" in <bound method SQLiteConnection.__del__ > of > <sqlobject.sqlite.sqliteconnection.SQLiteConnection instance at > 0x00B18878>> ignored > > Thanks, > Donnal Walter > Arkansas Children's Hospital > > > > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & > EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle > Practices > Agile & Plan-Driven Development * Managing Projects & Teams * > Testing & QA > Security * Process Improvement & Measurement * > http://www.sqe.com/bsce5sf > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > |
From: Kevin D. <da...@gm...> - 2005-08-30 16:56:12
|
pysqlite 2.x is only supported by SQLObject 0.7. I'd really recommend going with 0.7 anyhow, especially now that it's in beta. There doesn't seem to be much of anything up on sqlobject.org about it yet, but you can get it from the Cheeseshop: http://cheeseshop.python.org/pypi/SQLObject/0.7b1 Kevin On 8/30/05, Donnal Walter <don...@ya...> wrote: > --- Ian Bicking <ia...@co...> wrote: > [snip] > > SQLite sounds like the right choice for you. >=20 > Ok, thanks. So I installed SQLObject 0.6.1 (Windows XP, Python 2.4) > and pysqlite 2.0.3 for Python 2.4. My site-packages folder now has > the packages 'sqlite' and 'pysqlite2'. The latter has a 316 KB file > named '_sqlite.pyd', so I should not need to install SQLite > separately, correct? It also contains the module dbapi2.py. >=20 > But I can't find where sqlbject.sqlite.sqliteconnection ever > imports this package/module. I tried renaming the 'pysqlite2' > package to 'sqlite', but that didn't help. I know I am missing > something simple, but I can't quite put my finger on it. >=20 > ##=3D=3D=3D=3D=3D=3D=3D test code > from sqlobject import * > import sys, os >=20 > db_filename =3D os.path.abspath('mydata.db') > if os.path.exists(db_filename): > os.unlink(db_filename) >=20 > # had to add '/' from the example in online introduction > connection_string =3D 'sqlite:' + '/' + db_filename >=20 > connection =3D connectionForURI(connection_string) > sqlhub.processConnection =3D connection >=20 > =3D=3D=3D=3D=3D=3D=3D traceback > Traceback (most recent call last): > File "C:\Python24\Lib\site-packages\mindwrapper\tryout\try.py", > line 8, in ? > connection =3D connectionForURI(connection_string) > File "C:\Python24\Lib\site-packages\sqlobject\dbconnection.py", > line 658, in connectionForURI > conn =3D self.schemeBuilders[scheme]().connectionFromURI(uri) > File > "C:\Python24\Lib\site-packages\sqlobject\sqlite\sqliteconnection.py", > line 28, in connectionFromURI > return cls(filename=3Dpath, **args) > File > "C:\Python24\Lib\site-packages\sqlobject\sqlite\sqliteconnection.py", > line 21, in __init__ > self._conn =3D sqlite.connect(self.filename) > AttributeError: 'module' object has no attribute 'connect' > Exception exceptions.AttributeError: "SQLiteConnection instance has > no attribute '_pool'" in <bound method SQLiteConnection.__del__ of > <sqlobject.sqlite.sqliteconnection.SQLiteConnection instance at > 0x00B18878>> ignored >=20 > Thanks, > Donnal Walter > Arkansas Children's Hospital >=20 >=20 >=20 > ------------------------------------------------------- > SF.Net email is Sponsored by the Better Software Conference & EXPO > September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practic= es > Agile & Plan-Driven Development * Managing Projects & Teams * Testing & Q= A > Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf > _______________________________________________ > sqlobject-discuss mailing list > sql...@li... > https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss > |
From: Oleg B. <ph...@ma...> - 2005-08-30 17:05:53
|
On Tue, Aug 30, 2005 at 12:56:07PM -0400, Kevin Dangoor wrote: > pysqlite 2.x is only supported by SQLObject 0.7. I'd really recommend > going with 0.7 anyhow, especially now that it's in beta. I recommend to use SQLObject 0.7b1, but if you are going to use BLOBCol to store binary data with embedded zeros (\x00) downgrade to PySQLite1. Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Donnal W. <don...@ya...> - 2005-08-30 17:21:32
|
--- Kevin Dangoor <da...@gm...> wrote: > pysqlite 2.x is only supported by SQLObject 0.7. I'd really > recommend going with 0.7 anyhow, especially now that it's > in beta. > > There doesn't seem to be much of anything up on sqlobject.org > about it yet, but you can get it from the Cheeseshop: > > http://cheeseshop.python.org/pypi/SQLObject/0.7b1 Thank you. After unzipping and using "setup.py install" I find: setuptools-0.5a13-py2.4.egg and SQLObject-0.7b1-py2.4.egg in the Python24/Lib/site-packages folder. In the latter, I find: EGG-INFO and sqlobject. 1. Can I now remove setuptools... .egg? 2. Can I now move sqlobject to site-packages and remove the SQLObject... .egg? 3. I get a little further in my test script now, but it says it is unable to open database file. ##======= from sqlobject import * import sys, os db_filename = os.path.abspath('mydata.db') if os.path.exists(db_filename): os.unlink(db_filename) connection_string = 'sqlite:' + '/' + db_filename connection = connectionForURI(connection_string) sqlhub.processConnection = connection ##======= Traceback (most recent call last): File "C:\Python24\Lib\site-packages\mindwrapper\tryout\try.py", line 8, in ? connection = connectionForURI(connection_string) File "C:\Python24\Lib\site-packages\SQLObject-0.7b1-py2.4.egg\sqlobject\dbconnection.py", line 907, in connectionForURI conn = self.schemeBuilders[scheme]().connectionFromURI(uri) File "C:\Python24\Lib\site-packages\SQLObject-0.7b1-py2.4.egg\sqlobject\sqlite\sqliteconnection.py", line 59, in connectionFromURI return cls(filename=path, **args) File "C:\Python24\Lib\site-packages\SQLObject-0.7b1-py2.4.egg\sqlobject\sqlite\sqliteconnection.py", line 47, in __init__ self._conn = sqlite.connect(self.filename, **opts) pysqlite2.dbapi2.OperationalError: unable to open database file Thanks so much, Donnal Walter Arkansas Children's Hospital |
From: Oleg B. <ph...@ma...> - 2005-08-30 17:33:20
|
On Tue, Aug 30, 2005 at 10:21:17AM -0700, Donnal Walter wrote: > db_filename = os.path.abspath('mydata.db') > if os.path.exists(db_filename): > os.unlink(db_filename) > connection_string = 'sqlite:' + '/' + db_filename Now yor URI is something like sqlite:/\path\to\mydata.db Looks very wrong from the parser point of view. It expects sqlite:///path/to/mydata.db For in-memory databases use sqlite:/:memory: Oleg. -- Oleg Broytmann http://phd.pp.ru/ ph...@ph... Programmers don't die, they just GOSUB without RETURN. |
From: Kevin D. <da...@gm...> - 2005-08-30 17:37:31
|
On 8/30/05, Donnal Walter <don...@ya...> wrote: > 1. Can I now remove setuptools... .egg? I'm a big proponent of setuptools and Python Eggs... So, in my opinion, the answer to whether you *should* remove setuptools is "no". However, as far as I can see you *can* remove setuptools if you also do #2. (I didn't see anything in the SQLObject code that specifically relies on pkg_resources, which comes with setuptools). > 2. Can I now move sqlobject to site-packages and remove the > SQLObject... .egg? You can, but again eggs are a good thing. They solve dependency problems and make packaging of Python projects overall much nicer. I would be surprised if you don't find yourself with setuptools and more eggs installed at a later time. > 3. I get a little further in my test script now, but it says it is > unable to open database file. Oleg answered this one. Kevin |
From: Ian B. <ia...@co...> - 2005-08-30 17:46:55
|
Kevin Dangoor wrote: > On 8/30/05, Donnal Walter <don...@ya...> wrote: > >>1. Can I now remove setuptools... .egg? > > > I'm a big proponent of setuptools and Python Eggs... So, in my > opinion, the answer to whether you *should* remove setuptools is "no". > However, as far as I can see you *can* remove setuptools if you also > do #2. (I didn't see anything in the SQLObject code that specifically > relies on pkg_resources, which comes with setuptools). You can remove it, but it might just get installed again later when another package uses it, and it's highly likely SQLObject won't work in the future without it installed. It's actually quite possible sqlobject-admin, for instance, will require it before 0.7 final is released. >>2. Can I now move sqlobject to site-packages and remove the >>SQLObject... .egg? > > > You can, but again eggs are a good thing. They solve dependency > problems and make packaging of Python projects overall much nicer. I > would be surprised if you don't find yourself with setuptools and more > eggs installed at a later time. You can't remove this; the SQLObject egg file is the actual code you installed. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Donnal W. <don...@ya...> - 2005-08-30 18:03:00
|
Ian Bicking wrote: > Kevin Dangoor wrote: > > Donnal Walter wrote: [snip] > > > 2. Can I now move sqlobject to site-packages and remove the > > > SQLObject... .egg? > > > > You can, but again eggs are a good thing. They solve dependency > > problems and make packaging of Python projects overall much > > nicer. I would be surprised if you don't find yourself with > > setuptools and more eggs installed at a later time. > > You can't remove this; the SQLObject egg file is the actual code > you installed. I can see that I need to become familiar with eggs. Although I had glanced at them in passing before, this is my first direct exposure to them. Obviously they were invented to serve a purpose, so I will play by the rules. But my first impression is that sqlobject.0.6 looked so clean and simple, while 0.7 looks ugly and complicated. YMMV, of course, and if it works, that is the most important thing. Thank you all again for the helpful information and quick turn around. Regards, Donnal Walter Arkansas Children's Hospital |
From: Kevin D. <da...@gm...> - 2005-08-30 18:19:43
|
On 8/30/05, Donnal Walter <don...@ya...> wrote: > Ian Bicking wrote: > > > Donnal Walter wrote: > [snip] > > > > 2. Can I now move sqlobject to site-packages and remove the > > > > SQLObject... .egg? > > > > You can't remove this; the SQLObject egg file is the actual code > > you installed. >=20 > I can see that I need to become familiar with eggs. Although I had > glanced at them in passing before, this is my first direct exposure > to them. Obviously they were invented to serve a purpose, so I will > play by the rules. But my first impression is that sqlobject.0.6 > looked so clean and simple, while 0.7 looks ugly and complicated. > YMMV, of course, and if it works, that is the most important thing. Just to clarify here: your suggestion should work. If you move the sqlobject package out of the egg and into the site-packages directory, it should work fine. From a user perspective, eggs (and easy_install) will allow you to install a complete setup with a single command. For example, I use the Kid template tool, and that requires ElementTree. Using easy_install, I can just say "easy_install kid" and it will get both Kid and ElementTree for me. Eggs are a *different* packaging form, but hopefully will end up making things less complciated for consumers of packages. (Eggs are also pretty easy for people who create and distribute python packages.) Is there anything else about 0.7 that looks ugly and complicated? IMHO, ugly and complicated is a good thing to stamp out. Kevin |
From: Donnal W. <don...@ya...> - 2005-08-30 19:07:44
|
--- Kevin Dangoor <da...@gm...> wrote: [snip] > Eggs are a *different* packaging form, but hopefully will end up > making things less complciated for consumers of packages. (Eggs > are also pretty easy for people who create and distribute python > packages.) Since I hope to distribute a Python package someday (perhaps with dependencies, but perhaps not), it would probably be worth my while to get familiar with eggs. So far my stuff has been simple enough that it doesn't even really require distutils, though I have used them. > Is there anything else about 0.7 that looks ugly and complicated? > IMHO, ugly and complicated is a good thing to stamp out. Nope. The actual sqlobject package inside the egg looks great. It was the unfamiliar package names with version numbers in them that threw me off at first. My current package includes a simple ODB of sorts using cPickle. A few potential users have suggested that RDB support would be nice. Let's say that down the road I decide to provide this support and to use SQLObject in my implementation. Could I use Python eggs to distribute SQLObject (and perhaps even pySQLite) with my package? Thanks again. |
From: Kevin D. <da...@gm...> - 2005-08-30 19:16:18
|
On 8/30/05, Donnal Walter <don...@ya...> wrote: > My current package includes a simple ODB of sorts using cPickle. A > few potential users have suggested that RDB support would be nice. > Let's say that down the road I decide to provide this support and > to use SQLObject in my implementation. Could I use Python eggs to > distribute SQLObject (and perhaps even pySQLite) with my package? The beauty of eggs is that you don't actually distribute the other packages "with" your package. You just say that your package requires it. You can also choose to allow for optional "features", of which pysqlite support (which would list pysqlite as a requirement) could be one. They also let you specify which version of a package you need, so that you can be sure the user has all that they need. Phillip Eby has a good page about eggs here: http://peak.telecommunity.com/DevCenter/PythonEggs Kevin |
From: Ian B. <ia...@co...> - 2005-08-30 20:14:51
|
Kevin Dangoor wrote: > On 8/30/05, Donnal Walter <don...@ya...> wrote: > >>Ian Bicking wrote: >> >>>>Donnal Walter wrote: >> >>[snip] >> >>>>>2. Can I now move sqlobject to site-packages and remove the >>>>>SQLObject... .egg? >>> >>>You can't remove this; the SQLObject egg file is the actual code >>>you installed. >> >>I can see that I need to become familiar with eggs. Although I had >>glanced at them in passing before, this is my first direct exposure >>to them. Obviously they were invented to serve a purpose, so I will >>play by the rules. But my first impression is that sqlobject.0.6 >>looked so clean and simple, while 0.7 looks ugly and complicated. >>YMMV, of course, and if it works, that is the most important thing. > > > Just to clarify here: your suggestion should work. If you move the > sqlobject package out of the egg and into the site-packages directory, > it should work fine. That is true -- the egg can be dissassembled easily enough. The .egg directory is actually added to sys.path by a file easy_install.pth, and you'll see it on sys.path after you've installed SQLObject. The reason for the path manipulation is that it allows different versions to be enabled or disabled at runtime (so, for instance, you could have two versions of SQLObject installed). Personally I never really look in site-packages, so I never really payed attention to what it looked like. -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Ian B. <ia...@co...> - 2005-08-30 20:19:33
|
Kevin Dangoor wrote: > On 8/30/05, Donnal Walter <don...@ya...> wrote: > >>My current package includes a simple ODB of sorts using cPickle. A >>few potential users have suggested that RDB support would be nice. >>Let's say that down the road I decide to provide this support and >>to use SQLObject in my implementation. Could I use Python eggs to >>distribute SQLObject (and perhaps even pySQLite) with my package? > > > The beauty of eggs is that you don't actually distribute the other > packages "with" your package. You just say that your package requires > it. You can also choose to allow for optional "features", of which > pysqlite support (which would list pysqlite as a requirement) could be > one. If you do want to distribute a complete package, you could distribute an archive full of eggs, and add the whole thing to the path; that way you wouldn't effect the global Python installation, and you'll have a controlled set of packages (instead of whatever versions happen to be installed). There's also work on installers for Eggs (basically porting the kind of work in py2exe and py2app to use Eggs). Someone made an initial release of an MSI generator (Windows installer) for Egg-based applications recently. These are somewhat distinct from easy_install, in that easy_install installs Python packages, and these installers create archives that include an application and its dependencies (including Python for Windows machines; I assume py2app for Mac relies on the standard Python install). -- Ian Bicking / ia...@co... / http://blog.ianbicking.org |
From: Kevin D. <da...@gm...> - 2005-08-31 02:37:29
|
On 8/30/05, Ian Bicking <ia...@co...> wrote: > These are somewhat distinct from easy_install, > in that easy_install installs Python packages, and these installers > create archives that include an application and its dependencies > (including Python for Windows machines; I assume py2app for Mac relies > on the standard Python install). py2app only relies on the standard Python install if you run it with that Python. If you run it with another Python, that Python will get bundled in. Which is a very good thing, given that Apple is *still* bundling 2.3, and Mac OS 10.3 did not even include a good 2.3, apparently. It is worth noting that the kinks have not been worked out of the process for using eggs with py2exe or py2app. I didn't realize that that new MSI builder uses eggs. I'll have to check it out. Kevin |
From: Cedric B. <wo...@in...> - 2005-09-01 10:20:54
|
debian sarge hi, I'm sure that the egg stuff is a nice idea... but it does complicate my installation : ( so what is the correct procedure to install this: http://cheeseshop.python.org/packages/source/S/SQLObject/SQLObject-0.7b1.tar.gz > mkdir py > mkdir py/build > cd !$ > wget http://cheeseshop.python.org/packages/source/S/SQLObject/SQLObject-0.7b1.tar.gz > tar -xzvf SQLObject-0.7b1.tar.gz > python setup.py build > python setup.py install --prefix /usr/local > cd /usr/local/bin > sqlobject-admin Traceback (most recent call last): File "/usr/local/bin/sqlobject-admin", line 3, in ? import pkg_resources ImportError: No module named pkg_resources Exit 1 > ls -1 /usr/local/lib/python2.3/site-packages/ FormEncode-0.2.1-py2.3.egg/ SQLObject-0.7b1-py2.3.egg/ cherrypy/ setuptools-0.5a13-py2.3.egg/ so this means that sqlobject now depends on FormEncode ? and how do I import sqlobject in the python interpreter?? do I have to add the path: /usr/local/lib/python2.3/site-packages/SQLObject-0.7b1-py2.3.egg/ to sys.path ??? Ced. -- Cedric BRINER Geneva - Switzerland |
From: Kevin D. <da...@gm...> - 2005-09-01 17:51:31
|
On 9/1/05, Cedric BRINER <wo...@in...> wrote: > I'm sure that the egg stuff is a nice idea... but it does complicate > my installation : ( It's a temporary complication, I think. Once it's the standard distribution mechanism, it will be even easier than the current mechanism. > so what is the correct procedure to install this: > http://cheeseshop.python.org/packages/source/S/SQLObject/SQLObject-0.7b1.= tar.gz >=20 > > mkdir py > > mkdir py/build > > cd !$ > > wget http://cheeseshop.python.org/packages/source/S/SQLObject/SQLOb= ject-0.7b1.tar.gz > > tar -xzvf SQLObject-0.7b1.tar.gz > > python setup.py build > > python setup.py install --prefix /usr/local If you already had setuptools (or got it first), this would have been: easy_install SQLObject (or, if that would have gotten 0.6.1 because 0.7 is beta: easy_install SQLObject=3D=3D0.7b1 ) > > cd /usr/local/bin > > sqlobject-admin > Traceback (most recent call last): > File "/usr/local/bin/sqlobject-admin", line 3, in ? > import pkg_resources > ImportError: No module named pkg_resources > Exit 1 (see below, at the end) >=20 > > ls -1 /usr/local/lib/python2.3/site-packages/ > FormEncode-0.2.1-py2.3.egg/ > SQLObject-0.7b1-py2.3.egg/ > cherrypy/ > setuptools-0.5a13-py2.3.egg/ >=20 > so this means that sqlobject now depends on FormEncode ? Correct. Previously, sqlobject included a validators.py that was copied out of FormEncode. >=20 > and how do I import sqlobject in the python interpreter?? do I have to > add the path: > /usr/local/lib/python2.3/site-packages/SQLObject-0.7b1-py2.3.egg/ > to sys.path ??? EasyInstall (which is effectively being used when you ran setup.py install) puts a .pth file in the site packages directory, when used without --prefix. The .pth file makes sure that the current versions of your eggs are available for use, so you can import them directly and normally. However, when you install as "multiversion" (which is a great development feature, because you can have two versions of a package around), or to some directory other than site-packages, EasyInstall does not create .pth entries. .pth files have to be in a site directory. If you put /usr/local/lib/python2.3/site-packages on your sys.path, you can do this in your program once and then be able to import sqlobject: import pkg_resources pkg_resources.require("SQLObject") Kevin |
From: Cedric B. <wo...@in...> - 2005-09-13 11:42:22
|
> > so what is the correct procedure to install this: yeah how do you do this on debian ? > > http://cheeseshop.python.org/packages/source/S/SQLObject/SQLObject-0.7b1.tar.gz > > > > > mkdir py > > > mkdir py/build > > > cd !$ > > > wget http://cheeseshop.python.org/packages/source/S/SQLObject/SQLObject-0.7b1.tar.gz > > > tar -xzvf SQLObject-0.7b1.tar.gz > > > python setup.py build > > > python setup.py install --prefix /usr/local > > If you already had setuptools (or got it first), this would have been: > easy_install SQLObject no, I did not. I installed the python2.3-setuptools/unstable from debian, but this not give the easy_install executable: http://packages.debian.org/cgi-bin/search_contents.pl?searchmode=filelist&word=python2.3-setuptools&version=unstable&arch=all so, how should I proceed on a debian sarge station. I'm stuck on this for a long time : ( (shame on me !) > However, when you install as "multiversion" (which is a great > development feature, because you can have two versions of a package > around), or to some directory other than site-packages, EasyInstall > does not create .pth entries. .pth files have to be in a site > directory. interesting > If you put /usr/local/lib/python2.3/site-packages on your sys.path, > you can do this in your program once and then be able to import > sqlobject: in ipython I've done this: > import pkg_resources > pkg_resources.require("SQLObject") pkg_resources.require("SQLObject") --------------------------------------------------------------------------- pkg_resources.DistributionNotFound Traceback (most recent call last) /home/system/briner/<console> /usr/lib/python2.3/site-packages/pkg_resources.py in require(*requirements) 543 544 requirements = parse_requirements(requirements) --> 545 to_install = AvailableDistributions().resolve(requirements) 546 for dist in to_install: 547 dist.install_on(sys.path) /usr/lib/python2.3/site-packages/pkg_resources.py in resolve(self, requirements, path, installer) 349 dist = best[req.key] = self.best_match(req, path, installer) 350 if dist is None: --> 351 raise DistributionNotFound(req) # XXX put more info here 352 to_install.append(dist) need definitely some help. Ced. -- Cedric BRINER Geneva - Switzerland |