Mailman 3 May 2007 - Distutils-SIG

keeping a local ~/pylib directory of installed modules (2)
by John Gabriele 16 May '07

16 May '07

I wrote: > I'm running on a server where I don't have root access. I've installed > my own Python into ~/py-2.5.1 (with a ~/py symlink), and created my > own ~/pylib directory for installing any extra packages I need. > > I'd like to start using Easy Install / setuptools to manage package > installation, and have read the "Custom Installation Locations" --> " Ok, I see. If you've got your own local Python installed that you can write to, and that python is the first on your $PATH, everything just works with no extra options and things just get installed into your own local ``lib/python2.n/site-packages`` dir. Don't need a ~/pylib for an all-local setup like this. ---John

1 0

Re: [Distutils] setup.py demo.C build (gcc vs. g++) (distutils)
by Phillip J. Eby 16 May '07

16 May '07

At 12:19 PM 5/16/2007 -0500, Mowry, Peter wrote: > > echo $CC $CPP $CXX $LDSHARED >g++ g++ g++ g++ Try this instead: python2.5 -c "import os; print os.environ['CXX']" Does it display the same thing?

2 1

Re: [Distutils] setup.py demo.C build (gcc vs. g++) (distutils)
by Phillip J. Eby 16 May '07

16 May '07

At 09:56 PM 5/15/2007 -0500, Mowry, Peter wrote: >set CC="g++" >set CC=g++ >Neither of these work :-( I may have misspoken; it may be the CXX variable you need to set, rather than CC. >I also tried: >python2.5 setup.py demo.C build --compiler=g++ > >python2.5 setup.py demo.C build --help-compiler >gives bcpp, cygwin, emx, mingw32, msvc, mwerks, unix (g++ is not an >option) That's because those are compiler *types*, not executables. To override the executables, you need to use environment variables like CC, CPP, CXX, CCSHARED, LDSHARED, etc. See the "customize_compiler()" function in the "distutils.sysconfig" module, as that's what sets the executable names that will be invoked.

2 1

import problem using setuptools (resend without html)
by henk-jan ebbers 16 May '07

16 May '07

I am using setuptools to creat a windows installer (using python setup.py bdist --format=wininst). setuptools creates a 'entry point', so it generates a .exe in the Scripts directory (this exe calls start.py) /base/ start.py b.py /lib/ __init__.py c.py start.py imports b.py (which has a global that is initialised) then start.py imports c.py c.py imports start.py (as far as I know this is not a circular import, because I am using only 'import xx', not 'from xx import ..') when running start.py directly (as 'python start.py') everything goes OK. My problem is when I run the .exe from the entry point in the Scripts directory. when start.py is imported from c.py and start.py on its turn imports b.py, b.py is completly initialised again. This behavious does not happen when start.py is called directly. what am I doing wrong? I also noticed that, when creating and installing a windwos instaler, the easy-install.pth does not get an entry for my application. Is this intended? best regards, Henk-Jan

2 6

Re: [Distutils] setup.py demo.C build (gcc vs. g++) (distutils)
by Phillip J. Eby 15 May '07

15 May '07

At 06:11 PM 5/15/2007 -0500, Mowry, Peter wrote: >Content-class: urn:content-classes:message >Content-Type: multipart/related; > boundary="----_=_NextPart_001_01C79746.62B92D4C"; > type="multipart/alternative" > >Ever seen this error? > >Build Error Description: >python2.5 setup.py demo.C build > >That creates a demo.so, and when I try to import it, it gives me the error: >ImportError: ./demo.so: undefined symbol: __gxx_personality_v0 > > >Hack to fix it: >I found one single helpful post about this on google: ><http://www.intevation.de/pipermail/thuban-list/2003-September/000230.html>http://www.intevation.de/pipermail/thuban-list/2003-September/000230.html >suggests: > >Do the link step of gdalwarp manually by copying the commandline >printed by setup.py and replacing the gcc with g++ >So I tried this, and I saw that setup.py prints the following 2 commands: >gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 >-Wstrict-prototypes -fpermissive -fPIC >-I/tool/pandora64/.package/python-2.5/include/python2.5 -c demo.C -o >build/temp.linux-x86_64-2.5/demo.o >gcc -pthread -shared build/temp.linux-x86_64-2.5/demo.o -o >build/lib.linux-x86_64-2.5/demo.so > >Then I simply manually rerun just the second command with g++: >g++ -pthread -shared build/temp.linux-x86_64-2.5/demo.o -o >build/lib.linux-x86_64-2.5/demo.so > >And now the import works and so does the python spam_system() function. > > >Non-Hack to fix it?: >Is there a non-hack way to fix this? > >I've seen this question on the internet but no answers so far. I >did check --help-compiler, and it only lists --compiler=unix, not >--compiler=g++ for ex. I believe you can use the $CC environment variable, e.g. CC=g++ python setup.py whatever should cause it to use g++ as the executable instead of gcc.

2 1

Re: [Distutils] automating __version__' ing issues
by Phillip J. Eby 15 May '07

15 May '07

At 11:45 AM 5/13/2007 -0400, Alexander Michael wrote: >SVN does support keywords, but you need to turn-on keyword >interpolation (see the SVN documentation describing properties for how >to do this), but I don't think you'll need this functionality. >Development release suffixes can be added with setuptools >(<http://peak.telecommunity.com/DevCenter/setuptools#managing-continuous-rele…>). > When using this technique, the setup.py version string must be the >*next* version (the one under development that is typically your SVN >Trunk). It only has to be the next version if you're using a prerelease suffix like "dev". For example "1.2-r5499" is SVN revision 5499 of an already-released version 1.2. If you *haven't* released 1.2, you want to call it '1.2.dev-r5499' instead, which compares less than '1.2', e.g.: >>> from pkg_resources import parse_version as pv >>> pv('1.2') > pv('1.2dev') True >>> pv('1.2-r5499') > pv('1.2') True >>> pv('1.2-r5499') > pv('1.2dev-r5499') True >Here's the rub-- it must be in setup.py and you probably want >to give your package access to it so that it can be reported. It >appears that the current idiom for solving this dilemma is to but a >release.py or version.py file in your package, which is sucked up into >the setup.py file with execfile (see ><http://kid-templating.org/trac/browser/trunk/setup.py> for an >example). You then manually maintain the version number in one place >(the release.py file). Yep, this is what most people do. I actually use a PEAK tool called "version" (peak.tools.version) which maintains a data file with the version, and does targeted search-and-replace operations on the files listed in a configuration file. This is a lot easier when you have documentation files that also need version information updated, and it also avoids the execfile pain.

3 11

Python module to: Talk to stdout/stdin for 64-bit Windows/Linux C++ application?
by Mowry, Peter 15 May '07

15 May '07

Hi, Background / Goal: My team's application does regressions by controlling our 64-bit Windows/Linux C++ application (SimNow, www.amd.com/simnow) via stdout/stdin with ("pexpect" for unix) and (python COM objects) for Windows (b/c popen doesn't work). However, I am trying to replace this with a unified windows/linux solution. The idea is to extend Python with a SimNow-control module. My sole goal in extending a python module is so our python regressions scripts can use python to control SimNow via SimNow's stdin/stdout interface. Sample Final results: import simnow simnow.start() # start simnow executable output1 = simnow.sendCommand("load platform x") # blocking call, sends simnow cmd, returns the output string Disutils: Does extending python with Disutils sound like the simple and clean way for my goal? Is there a simple cookbook solution for my goal? (Btw, someone on my team already embedded python into SimNow. But I think we actually want to extend python, so to control SimNow from our python regressions code/infrastructure.) --Thanks, any response is appreciated! Peter Mowry ("Pem") SimNow Team, Software Engineer AMD Organization

3 4

import problem using setuptools (resend without html)
by henk-jan ebbers 15 May '07

15 May '07

I examined which modules python has imported (sys.modules). when using the .exe in Scripts dir, most imports have 'mypackage' insert before module name, eg: mypackage.b but when importing from c.py, this does not happen; it is imported as b So python thinks it is another module.... This does not happen when running start.py directly (as 'python start.py') So I guess this is something done by setuptools, probably pkg_resources But...how do I solve this problem? best regards, Henk-Jan

1 0

import problem using setuptools (resend without html)
by henk-jan＠ebbersconsult.nl 15 May '07

15 May '07

I am using setuptools to creat a windows installer (using python setup.py bdist --format=wininst). setuptools creates a 'entry point', so it generates a .exe in the Scripts directory (this exe calls start.py) /base/ start.py b.py /lib/ __init__.py c.py start.py imports b.py (which has a global that is initialised) then start.py imports c.py c.py imports start.py (as far as I know this is not a circular import, because I am using only 'import xx', not 'from xx import ..') when running start.py directly (as 'python start.py') everything goes OK. My problem is when I run the .exe from the entry point in the Scripts directory. when start.py is imported from c.py and start.py on its turn imports b.py, b.py is completly initialised again. This behavious does not happen when start.py is called directly. what am I doing wrong? I also noticed that, when creating and installing a windwos instaler, the easy-install.pth does not get an entry for my application. Is this intended? best regards, Henk-Jan

1 0

import problem using setuptools
by henk-jan ebbers 15 May '07

15 May '07

1 0