Mailman 3 August 2008 - Distutils-SIG

bdist_rpm fails - how to change what's included in hard linking?
by Andy Theuninck 16 Aug '08

16 Aug '08

I'm trying to create an rpm package using bdist_rpm and it's failing. I can see exactly why it's failing, but I can't coax google into telling me how to fix it. First I see python create a tarball to put in the rpm's SOURCES: creating python-sybase-0.39 making hard links in python-sybase-0.39... hard linking Sybase.py -> python-sybase-0.39 hard linking blk.c -> python-sybase-0.39 hard linking cmd.c -> python-sybase-0.39 hard linking conn.c -> python-sybase-0.39 hard linking ctx.c -> python-sybase-0.39 hard linking databuf.c -> python-sybase-0.39 hard linking datafmt.c -> python-sybase-0.39 hard linking date.c -> python-sybase-0.39 hard linking datetime.c -> python-sybase-0.39 hard linking iodesc.c -> python-sybase-0.39 hard linking locale.c -> python-sybase-0.39 hard linking money.c -> python-sybase-0.39 hard linking msgs.c -> python-sybase-0.39 hard linking numeric.c -> python-sybase-0.39 hard linking setup.py -> python-sybase-0.39 hard linking sybasect.c -> python-sybase-0.39 tar -cf dist/python-sybase-0.39.tar python-sybase-0.39 gzip -f9 dist/python-sybase-0.39.tar removing 'python-sybase-0.39' (and everything under it) copying dist/python-sybase-0.39.tar.gz -> build/bdist.linux-i686/rpm/SOURCES One of the files required by setup.py (ez_setup.py) isn't getting hard linked. Thus, when rpmbuild unpacks the above tarball into the rpm BUILD directory and runs setup.py, it crashes with an ImportError. How do I adjust what files get hard linked into that tarball?

1 0

[issue33] zipped eggs cause various problems -- perhaps set default setting to unzipped?
by Zooko O'Whielacronx 15 Aug '08

15 Aug '08

New submission from Zooko O'Whielacronx <zooko(a)zooko.com>: per http://mail.python.org/pipermail/python-dev/2008-April/078505.html installing an egg (with easy_install or ./setup.py install) in zipped form results in stack traces without source code lines attached. I hereby propose that zip_safe=False should be the default, unless the package producer and/or the package consumer specifically indicates that they prefer to zip the egg. I might be persuaded to change my mind about this if I saw some performance measurements which showed that zip_safe=False had a high cost. I'm skeptical that it has a high cost, since I've used it extensively for months (habitually specifying zip_safe=False in my setup.py files) and I haven't noticed any performance problem. PJE wrote, on the python-dev thread: "Are you using Python 2.5? As of 2.5, the linecache module should correctly read the source line from the present location of the source file the module was loaded from, regardless of the file name specified in the traceback." Yes, this was with Python 2.5.1. Note that the module was loaded from a .pyc file inside a zipped .egg (in the failing case), or from a .pyc file in an unzipped .egg (in the succeeding case). In the succeeding case, the name of the .py file, which is encoded inside the .pyc file, had been rewritten during the install process. Changed 4 months ago by zooko ¶ Here is another case that I encountered yesterday in which eggs being zipped caused a problem: we're using py2exe to build a Windows executable. (Also we are using py2app to build a Mac app.) py2exe can't find Python modules inside zipped eggs, although it can of course find them in unzipped eggs if the egg is added to the PYTHONPATH. At one point my programming partner Rob Kinninmont was using a script named ["hatch-eggs.py" http://allmydata.org/trac/tahoe/browser/misc/hatch-eggs.py?rev=1879]. That script no longer appears to be needed in our build system, but at this moment I can't figure out how we give py2exe access to the modules from the eggs that we installed... It is possible that we've customized the build machine by setting a distutils config file to say "always_unzip=True". I hope not, because that would mean our build will fail in mysterious ways when run on a different machine. Changed 4 months ago by zooko ¶ Oh, there it is: our [setup.cfg http://allmydata.org/trac/tahoe/browser/setup.cfg?rev=1938]. This means our Windows build will work on other machines, unless they have one of our dependencies already installed and that dependency is installed in zipped form. In that case, we'll get some strange error quite late in the process -- possibly something like the module not being found at run-time. So, this is another example of how unzipped eggs Just Work in more contexts (py2exe) than zipped ones do. Changed 4 months ago by nbecker ¶ zipped eggs also breaks pydoc: http://permalink.gmane.org/gmane.comp.python.devel/93788 Also, not very convenient if you need to view the source or debug. Changed 1 month ago by zooko ¶ Here's another one: http://mail.python.org/pipermail/distutils-sig/2008-July/009694.html Changed 1 month ago by zooko ¶ Here's another person who had trouble which he wouldn't have had if eggs were unzipped by default: http://mail.python.org/pipermail/distutils-sig/2007-December/008554.html Okay, here's the latest entry: my co-worker Greg Hazel, not knowing about the setup.cfg hack that I described earlier in this ticket, installed one of Tahoe's dependencies onto a build machine, using the default behavior of easy_install. Therefore, later there was a mysterious run-time error in the resulting package of Tahoe. Unfortunately I didn't catch this and explain it to Greg right away, so instead he spent some of his time figuring it out himself. After working-around the problem somehow, he reported to his manager: "fixed. you can say thank you to python eggs for screwing up py2exe's automatic dependency detection". (This ticket was imported from my interim setuptools bug tracker: http://allmydata.org/trac/setuptools/ticket/4 ) ---------- messages: 85 nosy: zooko priority: bug status: unread title: zipped eggs cause various problems -- perhaps set default setting to unzipped? _______________________________________________ Setuptools tracker <setuptools(a)bugs.python.org> <http://bugs.python.org/setuptools/issue33> _______________________________________________

2 1

Re: [Distutils] --single-version-externally-managed bug?
by Phillip J. Eby 14 Aug '08

14 Aug '08

At 11:45 AM 8/14/2008 -0500, chris wrote: >I recently installed a package using python setup.py >--single-version-externally-managed --record record.txt option. In my >site-packaged folder, there is now two new folders and a file. > ><top-of-package-namespace>/ ><package>-<version>.egg-info/ ><package>-<version>-nspkg.pth What is the contents of the nspkg.pth file?

1 0

--single-version-externally-managed bug?
by chris 14 Aug '08

14 Aug '08

I recently installed a package using python setup.py --single-version-externally-managed --record record.txt option. In my site-packaged folder, there is now two new folders and a file. <top-of-package-namespace>/ <package>-<version>.egg-info/ <package>-<version>-nspkg.pth Now when I start up python, I get the message 'import site' failed; use -v for traceback When I do python -v, I get the following traceback: # installing zipimport hook import zipimport # builtin # installed zipimport hook # /usr/lib/python2.5/site.pyc matches /usr/lib/python2.5/site.py import site # precompiled from /usr/lib/python2.5/site.pyc # /usr/lib/python2.5/os.pyc matches /usr/lib/python2.5/os.py import os # precompiled from /usr/lib/python2.5/os.pyc import posix # builtin # /usr/lib/python2.5/posixpath.pyc matches /usr/lib/python2.5/posixpath.py import posixpath # precompiled from /usr/lib/python2.5/posixpath.pyc # /usr/lib/python2.5/stat.pyc matches /usr/lib/python2.5/stat.py import stat # precompiled from /usr/lib/python2.5/stat.pyc # /usr/lib/python2.5/UserDict.pyc matches /usr/lib/python2.5/UserDict.py import UserDict # precompiled from /usr/lib/python2.5/UserDict.pyc # /usr/lib/python2.5/copy_reg.pyc matches /usr/lib/python2.5/copy_reg.py import copy_reg # precompiled from /usr/lib/python2.5/copy_reg.pyc # /usr/lib/python2.5/types.pyc matches /usr/lib/python2.5/types.py import types # precompiled from /usr/lib/python2.5/types.pyc import _types # builtin # zipimport: found 78 names in /usr/lib/python2.5/site-packages/setuptools-0.6c8-py2.5.egg # /usr/lib/python2.5/new.pyc matches /usr/lib/python2.5/new.py import new # precompiled from /usr/lib/python2.5/new.pyc 'import site' failed; traceback: Traceback (most recent call last): File "/usr/lib/python2.5/site.py", line 415, in <module> main() File "/usr/lib/python2.5/site.py", line 400, in main paths_in_sys = addsitepackages(paths_in_sys) File "/usr/lib/python2.5/site.py", line 206, in addsitepackages addsitedir(sitedir, known_paths) File "/usr/lib/python2.5/site.py", line 169, in addsitedir addpackage(sitedir, name, known_paths) File "/usr/lib/python2.5/site.py", line 138, in addpackage exec line File "<string>", line 1, in <module> KeyError: 'enthought' # /usr/lib/python2.5/warnings.pyc matches /usr/lib/python2.5/warnings.py import warnings # precompiled from /usr/lib/python2.5/warnings.pyc # /usr/lib/python2.5/linecache.pyc matches /usr/lib/python2.5/linecache.py import linecache # precompiled from /usr/lib/python2.5/linecache.pyc import encodings # directory /usr/lib/python2.5/encodings # /usr/lib/python2.5/encodings/__init__.pyc matches /usr/lib/python2.5/encodings/__init__.py import encodings # precompiled from /usr/lib/python2.5/encodings/__init__.pyc # /usr/lib/python2.5/codecs.pyc matches /usr/lib/python2.5/codecs.py import codecs # precompiled from /usr/lib/python2.5/codecs.pyc import _codecs # builtin # /usr/lib/python2.5/encodings/aliases.pyc matches /usr/lib/python2.5/encodings/aliases.py import encodings.aliases # precompiled from /usr/lib/python2.5/encodings/aliases.pyc # /usr/lib/python2.5/encodings/ascii.pyc matches /usr/lib/python2.5/encodings/ascii.py import encodings.ascii # precompiled from /usr/lib/python2.5/encodings/ascii.pyc Python 2.5.1 (r251:54863, Jan 10 2008, 18:01:57) [GCC 4.2.1 (SUSE Linux)] on linux2 Type "help", "copyright", "credits" or "license" for more information. dlopen("/usr/lib/python2.5/lib-dynload/readline.so", 2); import readline # dynamically loaded from /usr/lib/python2.5/lib-dynload/readline.so # /usr/lib/python2.5/atexit.pyc matches /usr/lib/python2.5/atexit.py import atexit # precompiled from /usr/lib/python2.5/atexit.pyc # /usr/lib/python2.5/rlcompleter.pyc matches /usr/lib/python2.5/rlcompleter.py import rlcompleter # precompiled from /usr/lib/python2.5/rlcompleter.pyc

1 0

[buildout] improving zc.recipe.egg's README.txt
by Chris Withers 14 Aug '08

14 Aug '08

Hi All, What I'd like to do at the start of the "Script generation" section was cat the setup.py of the demo egg to show the entry point where the demo eggs defines its script. However, given that the demo egg is a binary egg, I can't decide what the best way to do this is. I'd thought of using the zipfile module to reach inside the egg, but I'm confused as to why -py2.3.egg files are specified in the test and work even though I'm running with python 2.4 and there's no python 2.3 in sight? Any ideas welcome... cheers, Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk

5 10

relocation R_X86_64_32 against `a local symbol' can not be used...
by Gour 14 Aug '08

14 Aug '08

Hi! I am trying to install pyswisseph (http://pypi.python.org/pypi/pyswisseph) extension on my x86_64 system, but building of extension fails with: [gour@nitai pyswisseph-1.74.00-0] python setup.py --verbose build rm -f *.o swetest libswe* gcc -c -g -O9 -Wall -pedantic swedate.c In file included from swephexp.h:80, from swedate.c:86: sweodef.h:201: warning: ISO C90 does not support ‘long long’ gcc -c -g -O9 -Wall -pedantic swehouse.c In file included from swehouse.c:62: sweodef.h:201: warning: ISO C90 does not support ‘long long’ gcc -c -g -O9 -Wall -pedantic swejpl.c In file included from swephexp.h:80, from swejpl.c:71: sweodef.h:201: warning: ISO C90 does not support ‘long long’ gcc -c -g -O9 -Wall -pedantic swemmoon.c In file included from swephexp.h:80, from swemmoon.c:182: sweodef.h:201: warning: ISO C90 does not support ‘long long’ gcc -c -g -O9 -Wall -pedantic swemplan.c In file included from swephexp.h:80, from swemplan.c:63: sweodef.h:201: warning: ISO C90 does not support ‘long long’ gcc -c -g -O9 -Wall -pedantic swepcalc.c In file included from swephexp.h:80, from swepcalc.h:75, from swepcalc.c:76: sweodef.h:201: warning: ISO C90 does not support ‘long long’ swepcalc.c: In function ‘calcserv’: swepcalc.c:169: warning: ‘rspeed’ may be used uninitialized in this function swepcalc.c: In function ‘nacalc’: swepcalc.c:134: warning: ‘rspeed’ may be used uninitialized in this function gcc -c -g -O9 -Wall -pedantic sweph.c In file included from swejpl.h:68, from sweph.c:66: sweodef.h:201: warning: ISO C90 does not support ‘long long’ sweph.c: In function ‘app_pos_etc_plan’: sweph.c:2143: warning: array subscript is above array bounds gcc -c -g -O9 -Wall -pedantic swepdate.c In file included from swephexp.h:80, from swepcalc.h:75, from swepdate.c:77: sweodef.h:201: warning: ISO C90 does not support ‘long long’ gcc -c -g -O9 -Wall -pedantic swephlib.c In file included from swephexp.h:80, from swephlib.c:79: sweodef.h:201: warning: ISO C90 does not support ‘long long’ gcc -c -g -O9 -Wall -pedantic swecl.c In file included from swejpl.h:68, from swecl.c:62: sweodef.h:201: warning: ISO C90 does not support ‘long long’ swecl.c: In function ‘swe_lun_occult_when_glob’: swecl.c:1093: warning: ‘tjd’ may be used uninitialized in this function ar r libswe.a swedate.o swehouse.o swejpl.o swemmoon.o swemplan.o swepcalc.o \ sweph.o swepdate.o swephlib.o swecl.o ar: creating libswe.a running build running build_ext building 'swisseph' extension skipping pyswisseph.c (build/temp.linux-x86_64-2.5/pyswisseph.o up-to-date) skipping swhdatetime.c (build/temp.linux-x86_64-2.5/swhdatetime.o up-to-date) skipping swhfmt.c (build/temp.linux-x86_64-2.5/swhfmt.o up-to-date) skipping swhsearch.c (build/temp.linux-x86_64-2.5/swhsearch.o up-to-date) gcc -pthread -shared build/temp.linux-x86_64-2.5/pyswisseph.o \ build/temp.linux-x86_64-2.5/swhdatetime.o build/temp.linux-x86_64-2.5/swhfmt.o \ build/temp.linux-x86_64-2.5/swhsearch.o -Lsrc -L/usr/lib -lswe -lpython2.5 \ -o build/lib.linux-x86_64-2.5/swisseph.so /usr/bin/ld: src/libswe.a(swedate.o): relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC src/libswe.a: could not read symbols: Bad value collect2: ld returned 1 exit status error: command 'gcc' failed with exit status 1 Here is the setup.py: [gour@nitai pyswisseph-1.74.00-0] cat setup.py #!/usr/bin/env python # -*- coding: utf8 -*- import os.path, sys From distutils.core import setup, Extension VERSION = '1.74.00-0' if 'build' in sys.argv or 'install' in sys.argv: instdir = os.path.dirname(os.path.abspath(__file__)) os.chdir(os.path.join(instdir, 'src')) os.system('make clean') os.system('make libswe.a') os.chdir(instdir) swemodule = Extension( 'swisseph', include_dirs = ['src'], libraries = ['swe'], library_dirs = ['src'], sources = ['pyswisseph.c', 'swhdatetime.c', 'swhfmt.c', 'swhsearch.c'] ) setup( name = 'pyswisseph', version = VERSION, description='Python extension to the Swiss Ephemeris', long_description="""Python extension to AstroDienst's Swiss Ephemeris library. Swiss Ephemeris homepage: http://www.astro.com/swisseph Now Python 3 compatible (experimental). Usage example: >>> import swisseph as swe >>> swe.set_ephe_path('/usr/share/ephe') # set path to ephemeris files >>> now = swe.julday(2007,3,3) # get Julian day number >>> res = swe.lun_eclipse_when(now) # find next lunar eclipse (from now on) >>> ecltime = swe.revjul(res[1][0]) # get date UTC >>> ecltime (2007, 3, 3, 23.347975596785545) >>> jd = swe.julday(2008,3,21) >>> swe.calc_ut(jd, swe.AST_OFFSET+13681)[0] # asteroid Monty Python 0.098474291148756998 >>> help(swe) Installation via: # python setup.py install """, author='S.Marquis', author_email='stnsls(a)gmail.com', url='http://pyswisseph.atarax.org', download_url='http://pypi.python.org/pypi/pyswisseph', classifiers=[ 'Development Status :: 5 - Production/Stable', 'Intended Audience :: Developers', 'Intended Audience :: Religion', 'License :: OSI Approved :: GNU General Public License (GPL)', 'Programming Language :: C', 'Programming Language :: Python', 'Topic :: Religion', 'Topic :: Scientific/Engineering :: Astronomy', 'Topic :: Software Development :: Libraries :: Python Modules' ], keywords='Astrology Ephemeris Swisseph', ext_modules = [swemodule] ) # End. I'm quite new (just started learning Python) with Python and its tools, but, afaik, "recompile with -fPIC" means that something is missing so that extension is not compiled properly. I use: [gour@nitai pyswisseph-1.74.00-0] gcc -v Using built-in specs. Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared \ --enable-languages=c,c++,fortran,objc,obj-c++,treelang \ --enable-threads=posix --mandir=/usr/share/man --enable-__cxa_atexit \ --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib \ --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.3.1 20080724 (prerelease) (GCC) on: [gour@nitai pyswisseph-1.74.00-0] uname -a Linux nitai 2.6.25-ARCH #1 SMP PREEMPT Mon Jul 14 14:56:27 UTC 2008 \ x86_64 AMD Turion(tm) 64 Mobile ML-34 AuthenticAMD GNU/Linux Any idea? Sincerely, Gour -- Gour | Zagreb, Croatia | GPG key: C6E7162D ----------------------------------------------------------------

1 1

Re: [Distutils] install --no-deps
by Phillip J. Eby 14 Aug '08

14 Aug '08

At 04:57 PM 8/13/2008 -0500, chris wrote: >There doesn't seem to be a --no-deps option for install the way there >is for develop. Is there a way to perform a python setup.py install >and not have it rely on looking for dependencies? Use "setup.py easy_install [options] ." (The "." means, install using the setup script in the current directory.)

1 0

install --no-deps
by chris 13 Aug '08

13 Aug '08

There doesn't seem to be a --no-deps option for install the way there is for develop. Is there a way to perform a python setup.py install and not have it rely on looking for dependencies? -Chris

1 0

Setuptools: build_requires?
by Jeroen Ruigrok van der Werven 13 Aug '08

13 Aug '08

So I am curious, why doesn't setuptools provide a build_requires directive similar to install_requires, but for python setup.py build? Right now a particular Python module will fail if you import said dependency somewhere in your code. Centralizing such a dependency in setup.py seems, to me, very logical. So what gives? -- Jeroen Ruigrok van der Werven <asmodai(-at-)in-nomine.org> / asmodai イェルーンラウフロックヴァンデルウェルヴェン http://www.in-nomine.org/ | http://www.rangaku.org/ | GPG: 2EAC625B Courage is not the absence of fear, but rather the judgment that something else is more important than fear.

2 1

Re: [Distutils] [Catalog-sig] High-availability for PyPI, mirroring infrastructures?
by Jim Fulton 13 Aug '08

13 Aug '08

Switching to distutils On Aug 13, 2008, at 1:22 PM, Tarek Ziade wrote: ... > Besides this feature, there's one feature we started to add on > zc.buildout but could be put in setuptools's PackageIndex as well I > believe : > > Adding timeouts for url openings, to speed up the processing. For > instance, when several urls are visited for > a given package, and when a server pointed by one of the url is > down, it can last forever. Speaking of speed, if someone wants a project, it would be really nice someday to make requests in parallel, either using threads or using an async-based library like Twisted. Jim -- Jim Fulton Zope Corporation

1 0