The tests referred to in the README haven't been distributed with 1.0,
but will be with 1.2. If shapely.geometry imports, the geos_c SO was
found and loaded. Thanks for checking, I'll be releasing 1.0.15 now.
On Mar 20, 2010, at 1:00 PM, Nicholas Bower wrote:
This seems to work at quick glance - geos etc imported when doing
"from shapely.geometry import asShape".
However the testing section of the readme says the following should
work. I'm not sure why it doesn't. Also, there is no alleged
"runalldoctests.py" etc.
% /usr/local/Python-2.4.6-SunCC/bin/python setup.py test
running test
running egg_info
writing requirements to Shapely.egg-info/requires.txt
writing Shapely.egg-info/PKG-INFO
writing top-level names to Shapely.egg-info/top_level.txt
writing dependency_links to Shapely.egg-info/dependency_links.txt
reading manifest file 'Shapely.egg-info/SOURCES.txt'
reading manifest template 'MANIFEST.in'
writing manifest file 'Shapely.egg-info/SOURCES.txt'
running build_ext
Traceback (most recent call last):
File "setup.py", line 27, in ?
classifiers = [
File "/usr/local/Python-2.4.6-SunCC/lib/python2.4/distutils/
core.py", line 149, in setup
dist.run_commands()
File "/usr/local/Python-2.4.6-SunCC/lib/python2.4/distutils/
dist.py", line 946, in run_commands
self.run_command(cmd)
File "/usr/local/Python-2.4.6-SunCC/lib/python2.4/distutils/
dist.py", line 966, in run_command
cmd_obj.run()
File "/usr/local/Python-2.4.6-SunCC/lib/python2.4/site-packages/
setuptools-0.6c11-py2.4.egg/setuptools/command/test.py", line 121,
in run
self.with_project_on_sys_path(self.run_tests)
File "/usr/local/Python-2.4.6-SunCC/lib/python2.4/site-packages/
setuptools-0.6c11-py2.4.egg/setuptools/command/test.py", line 101,
in with_project_on_sys_path
func()
File "/usr/local/Python-2.4.6-SunCC/lib/python2.4/site-packages/
setuptools-0.6c11-py2.4.egg/setuptools/command/test.py", line 130,
in run_tests
testLoader = loader_class()
File "/usr/local/Python-2.4.6-SunCC/lib/python2.4/unittest.py",
line 758, in __init__
self.parseArgs(argv)
File "/usr/local/Python-2.4.6-SunCC/lib/python2.4/unittest.py",
line 785, in parseArgs
self.createTests()
File "/usr/local/Python-2.4.6-SunCC/lib/python2.4/unittest.py",
line 791, in createTests
self.module)
File "/usr/local/Python-2.4.6-SunCC/lib/python2.4/unittest.py",
line 556, in loadTestsFromNames
suites = [self.loadTestsFromName(name, module) for name in names]
File "/usr/local/Python-2.4.6-SunCC/lib/python2.4/unittest.py",
line 532, in loadTestsFromName
parent, obj = obj, getattr(obj, part)
AttributeError: 'module' object has no attribute 'test_suite'
On Thu, Mar 18, 2010 at 11:33 PM, Sean Gillies
<[email protected]> wrote:
The pre-release sdist is at
http://gispython.org/dist/Shapely-1.0.15.tar.gz
Works fine on my linux2 and darwin machines. I've no sunos5 or
win32, but I'm certain the latter will work. Linux, OS X, and
Windows users don't really have to upgrade at all.
On Mar 18, 2010, at 1:22 PM, Nicholas Bower wrote:
sure - let me know where it is but i'll take a couple of days to get
back to you. Ironically i'll have to temporarily drop out ctypes
dependency for the test as that doesn't compile on solaris either
without some poking which i'm trying to fix also.
On Thu, Mar 18, 2010 at 11:04 PM, Sean Gillies
<[email protected]> wrote:
Why not? Would you be willing to test a snapshot sdist? If so, I'm
willing to release 1.0.15 as early as today.
On Mar 18, 2010, at 12:49 PM, Nicholas Bower wrote:
What are the chances of retrofitting this to 1.0 series also
(perhaps the current stable branch for most)?
I've run into this and have had to always drop shapely out of my
setuptools dependencies, building by hand, because of it and don't
want at this time to have to upgrade to 1.2 if I've the choice.
On Thu, Mar 18, 2010 at 10:32 PM, Sean Gillies
<[email protected]> wrote:
I decided to go with the simplest approach for 1.2b4:
http://trac.gispython.org/lab/changeset/1570
It seems that there's a find_library bug involving Solaris
http://mail.python.org/pipermail/new-bugs-announce/2009-February/004177.html
so I'm avoiding it. That function works fine on Linux and OS X.
On Mar 17, 2010, at 3:55 PM, Huw Lynch wrote:
You're right; my problems have been on solaris not using GNU libc. I
don't know quite what the purpose is, but if linked against GNU
libcm platform.libc_ver() returns quite a different result - a
specific libc code version rather than the file system libc version.
If you take a copy of platform.libc_ver(), disable the GLIBC_ match
string (worst case just replace it with GxxxLIBC_ so that it does
not match) then it correctly picks up the libc.so.6 version on linux
too.
I confirm that on solaris 10 with python compiled by Sun Studio
compilers libc.so.1 is required. sys.platform is sunos5
Alternatively or perhaps in addition, it might be worth adding an
override option to shapely so that users of new systems can specify
the libc version in their code.
Cheers & thanks for the quick response.
On 17 March 2010 17:45, Sean Gillies <[email protected]> wrote:
On Mar 17, 2010, at 3:00 AM, Huw Lynch wrote:
Hi
Bug report - is there a better place to post these?
I've temporarily turned off registration on the wiki while I figure
out what to do about spammers, but I'll gladly set you up with a
login.
Shapely has some issues if when not running on linux with libc.so.6
because libc.so.6 is hard-coded into shapely/geos/__init__.py and
not all platforms use v6. Solaris for example uses libc.so.1
can replace this..
free = CDLL('libc.so.6').free
with this which is more portable...
import platform
libc = platform.libc_ver()
free = CDLL(libc[0]+'.so.'+libc[1]).free
Cheers
I tested this on my Linux machine and it doesn't yield the 'libc.so.
6' that we need:
>>> free = CDLL('%s.so.%s' % platform.libc_ver()).free
Traceback (most recent call last):
File "<stdin>", line 1, in ?
File "/usr/lib/python2.4/site-packages/ctypes-1.0.2-py2.4-linux-
i686.egg/ctypes/__init__.py", line 340, in __init__
self._handle = _dlopen(self._name, mode)
OSError: glibc.so.2.3: cannot open shared object file: No such file
or directory
I'm happy to add a new solaris platform section to geos.py. Will you
specify the platform string and double-check that libc_ver() really
returns ('libc', '1') in your situation?
--
Sean
--
Sean
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community
--
Sean Gillies
Programmer
Institute for the Study of the Ancient World
New York University
--
Sean
_______________________________________________
Community mailing list
[email protected]
http://lists.gispython.org/mailman/listinfo/community
