I was using Python 2.6.5 to build my application, which came with sqlite3 3.5.9. Apparently though, as I found out in another question of mine, foreign key support wasn't introduced in sqlite3 until version 3.6.19. However, Python 2.7 comes with sqlite3 3.6.21, so this work -- I decided I wanted to use foreign keys in my application, so I tried upgrading to python 2.7.
I'm using twisted, and I couldn't for the life of me get it to build. Twisted relies on zope.interface and I can't find zope.interface for python 2.7 -- I thought it might just "work" anyway, but I'd have to just copy all the files over myself, and get everything working myself, rather than just using the self-installing packages.
So I thought it might be wiser to just re-build python 2.6 and link it against a new version of sqlite3. But I don't know how--
How would I do this?
I have Visual Studio 2008 installed as a compiler, I read that that is the only one that is really supported for Windows, and I am running a 64 bit operating system
download the latest version of sqlite3.dll from sqlite website and replace the the sqlite3.dll in the python dir.
sqlite3 is not a built-in module; it's an extension module (the binary is C:\Python26\DLLs_sqlite3.pyd (on my machine)). A pyd is a DLL with a different filename extension and only 1 entry point. There's also a sqlite3.dll, which contains the SQLite code. python.exe is not linked against either of those, and thus rebuilding python.exe has no point.
The next idea is to go to the pysqlite2 download site, and get the latest Windows installer for Python 2.6. Unfortunately there's no docs about which version of SQLite it contains; one needs to install it and then muck about:
>>> import sqlite3 as standard
>>> from pysqlite2 import dbapi2 as latest
>>> for m in (standard, latest):
... print m.sqlite_version
...
3.5.9
3.6.2
>>>
So, it contains only SQLite version 3.6.2, which doesn't have the real foreign key support that you want.
I suggest that you check the mailing list to see if your question is answered there, and if not ask about the possibility of a Python 2.6 installer containing a later SQLite (e.g. the one included with Python 2.7).
I decided I'd just give this a shot when I realized that every library I've ever installed in python 2.6 resided in my site-packages folder. I just... copied site-packages to my 2.7 installation, and it works so far. This is by far the easiest route for me if this works -- I'll look further into it but at least I can continue to develop now.
I won't accept this answer, because it doesn't even answer my question, but it does solve my problem, as far as I can tell so far.
Related
There are Python libraries that allow to communicate with a database. Of course, to use these libraries there should be an installed and running database server on the computer (python cannot communicate with something that does not exist).
My question is whether the above written is applicable to the sqlite3 library. Can one say that this library does not need any database to be installed (and running) on the computer? Can one say that sqlite3 needs only a file system?
SQLite only needs a filesystem, yes, it is not a standalone server. Instead, SQLite is an embedded database. The whole database driver is contained in a shared library loaded together with the Python executable, as needed.
You do need to have the libsqlite3 shared library installed; Python itself only includes the Python integration for that library.
For Ubuntu, for example, you'd install the libsqlite3-0 package; but since the Python package already depends on this this is not something you need to worry about, usually. Mac OS X already comes with the shared library installed, and on Windows I believe the Python Windows installer bundles the library with it. The ActiveState Python Windows distribution certainly does, for example.
If you want to compile Python from source, you'll have to install (at the very least) the SQLite development headers to enable compilation of the sqlite3 package.
No, sqlite package is part of Python standard library and as soon as you have Python installed, you may use sqlite functionality.
MartijnPieters noted, the actual shared library is not technically part of Python (this was my a bit oversimplified answer) but comes as shared library, which has to be installed too.
Practically speaking, if you manage installing Python, you have the sqlite available for your Python code.
As OP asked for for a need to install sqlite separately, I will not speculate on how to install Python, which is not able to work with it.
I'm using the svn-python bindings (libsvn) to power Trac on Windows.
Previous to the Tigris->Apache migration of Subversion, I was able to download the Python bindings (svn-python-*.exe) here:
http://subversion.tigris.org/servlets/ProjectDocumentList?folderID=11151&expandFolder=11151&folderID=260
What happened to those bindings under the new regime?
I think they're maintained externally, like at http://sourceforge.net/projects/win32svn/files/1.6.15/.
Yup:
The Apache Subversion project does not
officially endorse or maintain any
binary packages of the Subversion
software. However, volunteers have
created binary packages for different
distributions and platforms, and as a
convenience, we maintain a list of
links to them here.
The URL above is the only listed as having bindings at http://subversion.apache.org/packages.html#windows.
I needed these today. You can get the 1.6.6 source from Tigris and there is a path "packages\python-windows" which contains a readme and setup.py file. Combine those with the bindings from win32svn 1.6.15 and you can try to generate an installer.
However, it didn't fully work for me. I am getting errors (running mailer.py) saying that there is an error importing module _core (libsvn_core.dll as far as I can see). Not sure why, might be my system, maybe it will work for you.
In continuing to research a solution for this question on ServerFault:
https://serverfault.com/questions/221203/mercurial-hook-fails-on-windows
I discovered an interesting and somewhat disturbing thing: I have seem three different versions of Python on my machine (four if you count the "official" version which doesn't appear to have a DLL with it....). Here's shot from my file search tool:
More Info:
I am running Windows 7 64-bit
Both the TortoiseHG and the Mercurial directories are on my path, with the Mercurial directory listed first.
I have Python 2.6 installed in c:\Python26
I have no entry for any type of PYTHON-based environmental variable. (Should I?)
I suspect that this is the source of the my problem from the question above, but I thought I'd ask here, as this is particular issue is a Python deal.
I tried to replace both DLLs with each other, but when I use the one that comes with Mercurial, then TortoiseHg stops working.
It seems to me that "there should only be one" Python on my machine. How do I achieve that?
For the problem that you mentioned earlier, the mercurial package got installed within python under mercurial home but you are executing scripts under C:\python26. So you need to install and execute your script under mercurial python
As seth mentioned earlier it is perfectly ok to multiple python homes in the same machine but you just to pay attention when installing python libraries to make sure that you are under the right home which means you set the path right before calling python.
Side note: The Python installation in "C:\Python26" installs its DLL to the Windows directory, in your case "C:\Windows\SysWOW64".
Answering your serverfault question: As you installed Mercurial as standalone version, you'll have to place any packages that are accessed by hooks into Mercurial's library folder (if it has one, could also be "library.zip").
I would recommend you to uninstall the Mercurial standalone version and instead install Mercurial with pip. This makes updates easier and you can use your normal "site-packages" directory for both normal Python libraries and hg hooks.
I would assume that tortoise/mercurial have just embedded their own versions of python to do whatever they need to do.
I wouldn't worry about it, the DLLs won't stomp on each other -- the PATH is the last placed that windows searches to find DLLs.
See: http://msdn.microsoft.com/en-us/library/7d83bc18(v=vs.80).aspx
Each DLL is for that application. There is only one in your search path so you don't need to worry about conflicts.
Is something not working that prompted you to worry about this??
Your assumption that there should only be one is wrong, each application has bundled a specific version with a fixed API, you can't just drop another in and hope it'll work.
The Python DLL naming structure only provides the major version and revision numbers. You are probably looking at the DLLs for versions 2.6.1, 2.6.4, 2.6.5, and 2.6.6.
All of this doesn't really matter as long as each application contains its own copy of the python26.dll. Windows will not explore the PATH environment variable if there is a local copy of the file.
I'm trying to use PyUNO as a method to convert different document formats (doc, wordperfect, html, etc) to PDF from within my Django server. I'm having a heck of a time getting import uno to work. It seems to fail when doing import pyuno, with a message of ImportError: DLL Load Failed: The specified module could not be found.
The only way I can get this to work is to use the Python 2.6 that came with OpenOffice, but I really want to use my other 2.6 installation. The docs for PyUNO are all for Python 2.2, and reputed to be out-of-date.
I'm guessing that some (or all) of the following files need to be copied from the OpenOffice directory to my site-packages directory (or some subdirectory thereof):
pythonloader.py
pythonloader.uno.ull
pythonloader.uno.ini
pythonscript.py
pyuno.pyd
Has anyone had any success getting this to work?
This is on Windows.
For simply conversions, you needn't reinvent the wheel. Look at unoconv: http://dag.wieers.com/home-made/unoconv/
'Import uno' will automatically work IF the python interpreter was bundled with OpenOffice, or in some Linux systems where the packagers have done a lot of work for you already.
Alternative 1: For other Python installs on Win32 systems, you need to import three environment variables and add one item to your Pythonpath. The detailed tutorial is at http://user.services.openoffice.org/en/forum/viewtopic.php?f=45&t=36370&p=166783
The three environment variables you must get FROM your OO-installed-Python and add TO your other install of Python are:
(Using Python 2.6 and OO 3.1.2)
os.environ['URE_BOOTSTRAP'] = 'vnd.sun.star.pathname:c:\Program Files\OpenOffice.org 3\program\fundamental.ini'
os.environ['UNO_PATH'] = 'c:\Program Files\OpenOffice.org 3\program\'
os.environ['PATH'].append('c:\Program Files\OpenOffice.org 3\URE\bin;c:\Program Files\OpenOffice.org 3\Basis\program;')
The pythonpath item you must add TO your other install of Python is the location of the uno module:
sys.path.append('C:\Program Files\OpenOffice.org 3\Basis\program')
Now you can simply 'import uno'.
Pyuno is only compatible with a similar version of Python. Since OO 3.1 bundles Python 2.6.1, that pyuno is only compatible with another Python 2.6. Attempting to import uno into a different version of Python will cause a runtime error. But there's a way around that in Alternative 2.
Alternative 2: For other Python installs on WIN32 systems, you can ignore the Python-UNO bridge completely and use the Python-COM bridge instead. You must install one new module, and the API has a few differences, but you can use ANY version of Python, including Python3.
Install the pywin32module to get COM access: http://sourceforge.net/projects/pywin32/
Discussion on the API differences: http://user.services.openoffice.org/en/forum/viewtopic.php?f=45&t=36608&p=168179
I also need an answer to this. I'm using windows XP and have a system where I extract data from a SQL server DB and insert it into template excel files. I DON'T want to add macro's etc to the OpenOffice. but I want to use the service to produce these files.
However, the only way I seem to be able to import the uno modude is to use the python.exe from the openoffice directory. even then I can't associate this exec with the py files in my system for some reason, thus I have to put in full path names each and every time.
I know that in Linux, the Pyuno module is an addon and can be used in normal python, but in windows this doesn't seem to be the case. I have listed all the relevant path details from the python exec under openoffice and duplicated them in python 2.7, but pyuno still fails with unable to find DDL with no reference to what DDL.
I think the answer is "this is not possible." From other reading on the web, it appears that the stdlib used to compile/link the python executable from python.org is different from the stdlib used to compile/link the python.exe distributed with OpenOffice.org. I don't know why, and I'm still confused by the fact that both pythons give me the same startup messages. So I could be completely on the wrong track here.
I'm currently toying with python at home and I'm planning to switch to python 3.1. The fact is that I have some scripts that use python 2.6 and I can't convert them since they use some modules that aren't available for python 3.1 atm. So I'm considering installing python 3.1 along with my python 2.6. I only found people on the internet that achieve that by compiling python from the source and use make altinstall instead of the classic make install. Anyway, I think compiling from the source is a bit complicated. I thought running two different versions of a program is easy on Linux (I run fedora 11 for the record). Any hint?
Thanks for reading.
On my Linux system (Ubuntu Jaunty), I have Python 2.5, 2.6 and 3.0 installed, just by installing the binary (deb) packages 'python2.5', 'python2.6' and 'python3.0' using apt-get. Perhaps Fedora packages them and names them as RPMs in a similar way.
I can run the one I need from the command line just by typing e.g. python2.6. So I can also specify the one I want at the top of my script by putting e.g.:
#!/usr/bin/python2.6
Download the python version you want to have as an alternative, untar it, and when you configure it, use --prefix=/my/alt/dir
Cheers
Nik
You're not supposed to need to run them together.
2.6 already has all of the 3.0 features. You can enable those features with from __future__ import statements.
It's much simpler run 2.6 (with some from __future__ import) until everything you need is in 3.x, then switch.
Why do you need to use make install at all? After having done make to compile python 3.x, just move the python folder somewhere, and create a symlink to the python executable in your ~/bin directory. Add that directory to your path if it isn't already, and you'll have a working python development version ready to be used. As long as the symlink itself is not named python (I've named mine py), you'll never experience any clashes.
An added benefit is that if you want to change to a new release of python 3.x, for example if you're following the beta releases, you simply download, compile and replace the folder with the new one.
It's slightly messy, but the messiness is confined to one directory, and I find it much more convenient than thinking about altinstalls and the like.