Re: problems compiling pyscopg2 on Windows with Python 2.6

Chris Withers <[email protected]>
Newsgroups gmane.comp.python.db.psycopg.devel
Message-ID <[email protected]>
Jason Erickson wrote:
> The build is statically linked against the libpq libraries, so no 
> libpq.dll is required.  Interesting that it started working for you 
> after installing PostgreSQL locally.  Did you try installing the VC2005 
> ATL Security Update, too?  I wonder if the PostgreSQL install installs 
> what is missing...  What install package did you use to install Postgres?

I didn't do anything other that install PG. However, I just uninstalled 
it, and psycopg2 is still working...

>> What would be ideal for me would be a statically linked .egg on PyPI. 
>> Any chance of that happening? Would this need to be built for specific 
>> postgres versions?
> 
> There's a chance of it happing, just need to understand .egg & PyPI :). 
> The big thing I see there is does one tag along with the official 
> package listed there, or create a package listing specific to win32.  

I would be great if all the distributions were actually on PyPI, under 
the psycopg2 package, rather than having to rely on initd.org and 
stickpeople.com...

> Being combined with the official package would be ideal.  Also, someone 
> recommended to me to format the web page so that easysetup could point 
> to the page and download the package from that page.  This might be a 
> good initial first step.

If you just get access to the PyPI account, and put the releases there, 
it'll all "just work" with nothing needed from your part other than to 
learn how to do:

python setup.py bdist_egg sdist register upload

;-)

Chris

PS:
> At one time, I was thinking about building different version for 
> different Postgres versions, but it dawned on me that it doesn't make 
> any sense to do that.  I my opinion, as long as you are using the latest 
> libpq interface, you are good to go, as it is backwards compatible to 
> versions quite a ways back (I believe the current stuff works at least 
> as far back as the 7.4 line).  Unless others can come up with a good 
> reason to build against an older libpq, I think using the latest libpq 
> interface is best.

Didn't realise that, all good to hear, so no need for multiple versions :-)

-- 
Simplistix - Content Management, Batch Processing & Python Consulting
            - http://www.simplistix.co.uk
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.