We Keep Coding

How do I build a C Python Extension for Windows using Cygwin64?

To preface: my code works as I expect when compiling and running on Linux. However, this library needs to be compiled for use on a Windows machine. I looked in to a couple different options, and decided that using Cygwin to compile for Windows seemed to be the correct choice. I'm using a setup.py file with the distutils.core library and compiling using python setup.py install. When compiling on Windows in Cygwin, it fails to find pthread.h, arpa/inet.h, netinet/in.h, and sys/socket.h. I was under the impression that Cygwin came prepackaged with these headers, which is why I chose to use it. The alternative to Cygwin is putting preprocessor commands everywhere and using Windows specific libraries such as winsock2.h, which I want to avoid if at all possible. Is it possible to compile for Windows using Cygwin? If so, what have I done wrong to cause Cygwin to not recognize these headers?

You need to install the proper headers
$ cygcheck -p usr/include/pthread.h
Found 9 matches for usr/include/pthread.h
cygwin-devel-3.0.7-1 - cygwin-devel: Core development files
..
cygwin-devel-3.1.6-1 - cygwin-devel: Core development files
...
so install the cygwin-devel package
To check all the shared libraries needed by the built dll, you can use cygcheck
$ cygcheck /usr/lib/python3.8/site-packages/Cython/Compiler/FlowControl.cpython-38-x86_64-cygwin.dll
D:\cygwin64\lib\python3.8\site-packages\Cython\Compiler\FlowControl.cpython-38-x86_64-cygwin.
dll
D:\cygwin64\bin\cygwin1.dll
C:\WINDOWS\system32\KERNEL32.dll
C:\WINDOWS\system32\ntdll.dll
C:\WINDOWS\system32\KERNELBASE.dll
D:\cygwin64\bin\libpython3.8.dll
D:\cygwin64\bin\cygintl-8.dll
D:\cygwin64\bin\cygiconv-2.dll
D:\cygwin64\bin\cyggcc_s-seh-1.dll
As was built with Cygwin Python, you need also to transfer the cygwin python...

Most important, I think, is to follow the instructions in the Python help or on the Python doc web site for "Extending and Embedding the Python Interpreter" for the version you are building the extension for. For windows, the build instructions identify the build environment used to create the binary package that you download from python.org, usually something like VS2013 or VS2017. (As an aside, I think the Community editions have everything you need, and I don't think you actually have to use the Visual Studio GUI when you build using nmake from the CMD.EXE terminal.)
To build in Cygwin for use in a Windows version of Python, you may need to install and then use the x86_64-w64-mingw32-gcc, etc., cygwin packages to cross-compile non-cygwin (i.e. pure windows) executables and DLLs from Cygwin.
Binary extensions must be built using the source tree for a specific Python major.minor version, and bitness. For windows, you will need to build multiple versions of the extension, one for each major.minor, bitness version of Python that will import it, e.g. 3.6, 3.7, 3.8, 3.9, 32-bit, 64-bit. The extension code may not require changes between versions, but it still needs to be compiled with the right compiler and linked against exactly the same shared libraries (in this case .DLL files) as used by the Python executable. For instance, it must use exactly the same version of Microsoft's C run time library DLL as the Python executable does. This is a bit more sensitive and restrictive than on Linux, where you can rebuild the python executable and your extension with the same toolchain from your distro more easily.

Installing and using python on a client computer

I am writing a small python installer application that will run on linux. However, i don't know which Linux in advanced, so i cant write for any specific python version since i have no idea what is installed on the client computer, if any (do i? is there any thumb rule for python version preinstalled on a Linux machine?).
Is there a optimal way to install a local python version on a client's computer in some temporary directory, use it for the application run-time, than remove it when it is done?

Do you know the machines architecture? If so simply download the python version you want to install on the linux architecture on your server/box/your computer then compress it and upload it to a server somewhere. (or use the link on python.org)
then simply make a bash script to download it and uncompress it. Then install it using shell commands like make or cmake ./configure within the install directory
If you dont know the architecture or are trying to use it on some generic or other you could cross compile it using these cross compilers to cross compile python (or anything coded in c(/c++?))
http://pastebin.com/mxWqBvy8
Typically the general 'rule of thumb' for the python version would be python2.7.x
You could use Pyinstaller to "compile" your python (its origanally win) there is a linux version somewhere, fairly sure its as easy as pyinstaller test.py)
Removing it shouldnt be that hard, rm is universal everywhere

You can bundle your programs with Python itself without requiring the target machine installed Python Interpreter on it.
Check this out: https://wiki.python.org/moin/Freeze

Installing rpm module for (non-system) Python

I need to support some software that is using an old Python version (2.4). So I have downloaded and compiled Python 2.4 and installed it in a virtualenv. So far, all OK and normal procedure.
But the software is trying to import an rpm module. And I cannot find a source for that module (it is not part of the standard Python library, afaict).
Typically, once the virtualenv is enabled (source env/bin/activate) I can install required software using easy_install. But easy_install rpm is failing to find anything. There is a pyrpm module, but it is not the same thing (it installs a module called "pyrpm"). And google searches are useless, as they all link to articles on how to build rpms...
If I were using the system python (on Ubuntu) I could install the python-rpm package. But that is for Python 2.7. How do I install the equivalent for Python 2.4?
[My impression is that the rpm libraries, used by many Linux systems, include a Python library, which is packaged as python-dev by the distro. But I can't see how to access that for an arbitrary python version.]
I AM NOT LOOKING FOR AN RPM THAT CONTAINS PYTHON 2.4. I AM LOOKING FOR A MODULE NAMED rpm THAT IS USED BY SOFTWARE WRITTEN FOR PYTHON 2.4.

It's right there, in the python-rpm RPM package:
http://rpmfind.net/linux/rpm2html/search.php?query=python-rpm
You will probably want to download the package contents, extract them, and then use
python setup.py install
From your active environment.
Of course, as it's pre compiled, you might have trouble getting the C extension to run.
I'm not familiar enough with RPM's to know whether you can get the source from there.
No guarantees the package will work with your python version though.

there's no simple way to do this; the python library is part of the system rpm package and interfaces to C code, so is closely tied to the rpm package installed on your machine.
instead, it's much simpler to install an old OS in a VM (eg CentOS 5) that uses Python 2.4. then everything is consistent and works.

the sources for the rpm module can be found here: http://www.rpm.org/wiki/Download
After you download the wanted version read and follow the INSTALL instructions in order to compile it on your target OS. Afterwards make sure you add the correct path to the 'site-packages' folder the installation chose into your PYTHONPATH environment variable.
To test start your python interpreter and run 'import rpm'
HTH,
Ran

Opencv 2.2 not recognized on Python 2.7 (Ubuntu/Windows XP)

I've been trying to connect opencv and python in both Ubuntu and Windows XP. I've failed on both.
I've read many webpages and threads about "how to install" it but none has worked (the worst part is that they all say kind of the same).
Steps (windows xp):
Installed Python 2.7 by default (works perfectly)
Installed PIL and cx_Freeze (may they
create a conflict? I don't think so
:s)
Installed Opencv 2.2 by default
(OpenCV-2.2.0-win32-vs2010.exe) and
it isn't recognized inside a py nor
as import opencv.cv nor using the
cookbook way, import cv (I skipped
the visual studio steps since I'll
use it with python)
Checked path (it's ok, it has the
Opencv2.2\bin thing)
Rechecked webpages and stuff
Steps (ubuntu):
Had python working
sudo apt-get install, cmake, make,
sudo make install, etcetc (from the
tutorials)
same thing... module not recognized
Please can you help?
Update:
I managed to install it and have it recognized by the system (I used http://www.lfd.uci.edu/~gohlke/pythonlibs/#opencv and it worked perfectly after that).
The problem now is that it crashes when I try to use CaptureFromFile. Someone else has reported it 3 days ago so now I wait.
I'll check the other wrappers, maybe one of them will work.

For windows see my web page: http://www.modernmind.org/wiki/OpenCV
For Ubuntu you should just need to apt-get install python-dev then generate the make files with Cmake, build it and then make install. In order to build the python bindings you need to have the python header files on your system and you probably don't. When you run configure in Cmake make sure that you don't see any messages at the top about PYTHON_INCLUDE not being defined.

To access a library it needs a Python library installed in the Python version you are using. From what you write above it seems to me that you install OpenCV in general, but that you don't specifically install the Python library. This is why it doesn't work.
I'm not sure how to install the Python wrappers, and the OpenCV documentation is a bit sparse on that info. But if you did build them (and that needs to be turned on explicitly, says the docs) they seem to end up in opencv/release/lib .
Look at "Testing Python wrappers" on http://opencv.willowgarage.com/wiki/InstallGuide
If there is still no luck, there is a bunch of alternative Python wrappers available: http://pypi.python.org/pypi?%3Aaction=search&term=opencv&submit=search
Maybe they are better documented.

Installing Trac with Subversion 1.6

I'm trying to set up Trac on my server and have successfully installed it, compiled the bytecode and run the tracd server. The only problem is that it's not reading my SVN repository.
The error I'm receiving is:
Warning: Can't synchronize with the repository (Couldn't open Subversion repository /data1/repos: SubversionException: ("Expected FS format '2'; found format '4'", 160043)). Look in the Trac log for more information.
(Yes, my single repository is in a folder called "repos" - I didn't set that bit up)
The trac.ini looks like this:
repository_dir = /data1/repos
repository_type = svn
I'm running: Trac 0.11.5, Python 2.4.3, Collabnet SVN 1.6.5, SWIG 1.3.29

Is your python svn library updated? Sounds like it's stale.

you should make sure the python binding match your SVN version.
to get the binding you can use the SVN source and compile the wrapper, the install give an overview of the process how to build that binding.
first you would have to download the svn source
BUILDING SWIG BINDINGS FOR SVN ON UNIX
after build the swig binding
Step 1: Install a suitable version of
SWIG (which is
currently swig version 1.3.24 - 1.3.31).
* Perhaps your distribution packages a suitable version - if it
does
install it, and skip to the last bullet point in this section.
* Go to http://www.swig.org/, download the source tarball, and
unpack.
* In the SWIG-1.3.xx directory, run ./configure.
If you plan to build the Python bindings, and have a system
with more than one version of Python installed, you may need
to pass
--with-python=/path/to/correct/python/binary
to the configure script. You need Python 2.4 or above.
If you plan to build the Perl bindings, and have a system
with more than one version of perl installed, you may need
to pass
--with-perl5=/path/to/correct/perl/binary
to the configure script. You need Perl 5.8.0 or above.
* Build and install.
Run 'make && make install'
* To verify you have SWIG installed correctly, run "swig
-version"
from the command line. SWIG should report that it is version
1.3.24
or newer.
and then python things
Step 3: Install Specific Language
Bindings
Python
Run 'make swig-py' from the top of the Subversion source tree,
to build the bindings.
(This will invoke SWIG on the *.i files, resulting in a collection
of .c source files. It will then compile and link those .c files
into
Python libraries.)
Run 'make check-swig-py' from the top of the Subversion source
tree, to test the bindings
Run 'make install-swig-py' (as root, typically)
from the top of the Subversion source tree. This will copy
your new Python libraries into the appropriate system location.
Note: If you don't have access to install to Python's site-packages
directory, you can have the Python modules install to your home
directory. You can do this by running
'make install-swig-py swig_pydir=~'.
Note: If you want to install to an alternate prefix (usually only
if you are building packages), you can supply the prefix here. An
example of doing this for building rpms looks like
'make install-swig-py DESTDIR=$RPM_BUILD_ROOT/usr'.
Make sure that whatever directory the bindings got installed
in
is in your Python search path. That directory depends on how you
installed; a typical location is /usr/local/lib/svn-python/.
There are several ways to do this. See Python's documentation for
'sys.path' and 'PYTHONPATH'. A nice way to do this is:
$ echo /usr/local/lib/svn-python \
/usr/lib/python2.x/site-packages/subversion.pth
You may also need to update your operating system's dynamic linker
configuration to enable Python to load these new libraries. On some
systems this is done by running 'ldconfig'.

It may be that the Subversion Python bindings are compiled against a too-old version of Subversion, but given FS format 2 is pre-1.0, it's possible something else is wrong. You can get the Subversion client library version like this:
>>> import svn.client
>>> svn.client.svn_client_version().major
1
>>> svn.client.svn_client_version().minor
6
>>> svn.client.svn_client_version().patch
5

Looks like these guys answered your question pretty thoroughly but FYI: setup the log file so you can read it during your next problem. In your trac.ini somewhere:
[logging]
log_file = trac.log
# log_format = <inherited>
log_level = DEBUG
log_type = file
After that, try to deploy trac to apache if possible - with mod_python or FastCGI the trac documentation says it's a lot faster than running tracd.