[Community] Rtree installation errors
sean.gillies at gmail.com
Sun Sep 13 10:48:35 EEST 2009
On Sep 13, 2009, at 4:32 AM, Howard Butler wrote:
> On Sep 12, 2009, at 1:49 PM, Sean Gillies wrote:
>> Rtree 0.5, I presume? It seems that the released code was broken. See
> libspatialindex_c.so only exists in trunk of libspatialindex. It has
> not yet been released. The code was part of 0.5.0, but it was not
> called libspatialindex_c. To use rtree from trunk, you must also use
> a trunk libspatialindex. The error below is from this condition. As
> far as I know, only Brent Pederson and I have been using this so far.
>> Please revert to 0.4.3. I'm going to propose that we pull 0.5, do a
>> review, more testing and then make a new release.
> Except for the PYTHONPATH/egg issue, which is pretty easy to work
> around, the 0.5 passed all of the tests in the test suite. Why should
> we retract the release, especially for a software called 0.x instead
> of 1.anything? I bent over backwards to make sure that the new code
> passed all of the tests in the suite and show that we had functional
> parity with what existed before, and telling people to go back,
> especially considering all of the new functionality (with no
> performance degradation), feels like a smack. In the run up to 0.5.0,
> I was clamoring for testing and heard practically nothing.
> In the meantime, Brent and I have continued to work on rtree toward a
> 0.6 release, which will include sphinx docs, a bunch of performance
> tweaks by Brent, and the movement of the C/C++ code into
> libspatialindex proper. The holdup is getting a new libspatialindex
> released, and the holdup on that is I have a few more C API items I
> want to implement for libspatialindex_c like tree walking that can
> make it back into Rtree when we get time.
> Let's move forward on releases, not backwards. When it comes time to
> prep for a release, let's ensure that we're testing stuff more
> widely. 0.5.0 might be a little hinky when it comes to installation,
> and 0.6+ is going to require a specific version of libspatialindex
> (and above). I guess we could start a maintenance branch using 0.4.x,
> but I'm not helping to maintain it.
The 0.5 sdist release doesn't work. Maybe we just pull that? Feels
weird to me because IMO the sdist is the canonical release and eggs
are just for convenience.
More information about the Community