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.
Related
I'm working in the VFX industry and we deal with different software packages that ship with their own Python interpreter. We are running on Linux and use modules to handle our environments to make sure that people are using the correct version of all applications depending on the project they are working on.
Since months, we are trying to setup an environment that supports multiple versions of Python. And what is blocking right now are additional Python libraries that we are using in our in-house tools, like sqlalchemy, psycopg2, openpyxl, zmq, etc.
So far, for each project, we have config file that defines the version of each package to be use including the additional Python modules. And to use the correct Python version of each Python module, we look up the main Python interpreter defined in that same modules definition file. This works as long as the major and minor versions of all Python interpreters do line up.
But now, I would like to start an application that ships with a Python 3.7 interpreter and another application with a Python 3.9 interpreter and so on. All applications do you use our in-house tools which need the additional Python modules. Of course, this fails when trying to import any additional module.
For now, the only solution that I see is to install the corresponding Python modules in the 'site-packages' of each application that comes with its own Python interpreter. That should work. But this means that we have to install for each application version all necessary Python modules (ideally, the same version of it to avoid compatibility issues) and when we decide to update one of them, this needs to be done again for all 3rd party applications.
That does not sound super-efficient to me.
Do you have similar experiences and what did you came up with to handle this? I know, that there are more advanced packages like rez to handle complex environment setups, but although I do not know the details of rez, I could imagine that the problems stays the same. I guess that it is not possible to globally populate PYTHONPATH with additional modules so that it works on multiple Python interpreter versions.
Another solution that I could imagine is to make sure that on startup of each application that needs additional Python modules, we do our own sys.path modification depending on the interpreter version. That would imply some coding but we could keep a global version handling without installing them everywhere.
Anyway, if you have any further hints, please let me know.
Greets,
Carlo
I'm looking for a way to call my python project and display the console on my c# app.
My python project is a bit particular, i use some specific librairy, i even have to install a package whl not avalible with pip, avalible only with python3.7(not with 3.8) etc. So to run the project, i need python 3.7 exactly.
The problem is also that i want to deploy my c# app in ClickOnce to be use by clients, without having them to install a local python version.
I've seen on the net two ways to do work with python and c#, that both doesn't seem working for my need.
using python in c# app
1.Call python in a shell
I've imported the python project in my c# app, i've called the python.exe avalible in the venv and i've deployed the app. Everithing seems to work, but i discover that python executable in the venv refer to the local python installation and doesn't seem autonomus. So it was only working for me and not the clients.
Use IronPython in c#
Really far from working, starting by the encoding blowing from everywhere, even in imported librairy like numpy. I've referenced my venv librairy in SetSearchPaths(), and even with that, it's doesn't seem to work.
Any suggestions? The best way i think, would be to have a python.exe independant following the project that can load my venv.
Python.Included and the Numpy.NET package made with it may work for this:
https://github.com/henon/Python.Included
https://github.com/SciSharp/Numpy.NET
They are introduced in this post from 2019 and seem to be in active development today, https://medium.com/scisharp/using-python-libraries-in-net-without-a-python-installation-11124d6190cf
That solution does not use IronPython, but Python.NET: https://github.com/pythonnet/pythonnet
IronPython is an implementation of Python in C#, championed by others and then Microsoft itself back in 2010 era. Later Microsoft dropped it and largely the whole notion of supporting dynamic languages on .NET (they made a DLR system for it back then). It is very cool and works for pure Python code.
But NumPy and many useful and popular Python modules are written in C, using the C API of Python.org 's default C written Python implementation, aka. CPython. This is what Microsoft decided to back too instead, because C written Python modules don't work (easily and well) with IronPython. Also IronPython remains at Python 2.7.
Python.NET just bridges the .NET land with the normal CPython interpreter, so that you can call code cross the language boundary. So Numpy and everything works the same as with Python usually. Which is what you want.
Python.Included is one way to deploy that in C# projects - which may or may not work for you, but at least provides a starting point:
Python.Included is an automatic deployment mechanism for .NET packages
which depend on the embedded Python distribution. This allows
libraries depending on Python and/or Python packages to be deployed
via Nuget without having to worry about any local Python
installations.
It packages embedded Python (python-3.7.3-embed-amd64.zip) in its .NET
assembly and automatically deploys it in the user's home directory
upon first execution. On subsequent runs, it will find Python already
deployed and therefor doesn't install it again.
If you don't want to use that install mechanism, I think you can just bundle the CPython interpreter with your C# application and use the Python.NET mechanism to call that from your app's directory instead.
I have created a python library using sklearn and some other dependencies. I want other developers to be able to use it in their programs, in a non-public environment(e.g.within a organization) They will use this library for to write their own applications.
Some questions that I have are -
What is a best way to make it available to other developers?
Let's say , the developers have their own python installation, and they use a version 1.x of a package(e.g. sklearn etc) but my
package uses 2.x, will there be a problem? If yes, how can i ensure they
can use my library.
I want to make my library available for both Python 2.7 and 3.x users. Do I need two different deployments? Currently my library
works(no version specific calls for 2.7/3.x) in both 2.7 and 3.x, if
the correct dependencies are pre-installed by the user.
The best way is to publish at PyPI. That way your user have ti just run pip install $LIB and got it with all dependencies (if you properly configured dependencies). See Python Packaging User Guide.
Just recommend your users to use virtualenv. Virtual environments are the way to separate and install different versions of Python libraries and programs to coexist at one system.
Very much depends on the nature of your library. There are libraries that can be installed to both Python 2 and 3 from one source and there are libraries that require different package for every python version.
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 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.