[C++-sig] New Major-Release Boost.Python Development
talljimbo at gmail.com
Fri Aug 26 21:01:18 CEST 2011
On 08/25/2011 04:26 PM, Ralf Grosse-Kunstleve wrote:
> Hi Jim,
> CC to Dave.
> This is great news.
> My main interests have been stability and not increasing the memory
> footprint of boost.python extensions. I'm not in a position to further
> develop boost.python.
> Troy and Ravi have done a significant amount of work. I hope they will
> comment for themselves.
> I'd prefer if developments stayed under the boost umbrella, e.g. as
> boost/python/v3, but I don't feel very strongly about this.
I'd have no problem at all calling it boost/python/v3 (in fact I'd hope
to). Essentially, my concern is that v3 would fall into a muddy
category between an accepted Boost library and a proposed Boost library,
and I don't have a good example of how that ought to work, with regard
to whether it should exist in the Boost main repository, or even whether
it can even use the Boost label.
And I would like to have both v2 and v3 available simultaneously as
distinct libraries (the way Python 2 and Python 3 are, for instance), at
least while v3 is undergoing lots of changes. I'm not sure how to fit
that model into the Boost umbrella - I'm happy to do it, but I guess I'm
hoping for someone to tell me how it should fit; I don't want to presume
that v3 is automatically a Boost library without permission, so it
seemed safer to move it outside until it could officially win back its
Boost status through review.
> On Thu, Aug 25, 2011 at 1:59 PM, Jim Bosch <talljimbo at gmail.com
> <mailto:talljimbo at gmail.com>> wrote:
> I'd like to start work on a new major release of Boost.Python.
> While the library is currently well-maintained in terms of
> bugfixes, I get the sense that neither the original developers nor
> the current maintainer have the time or inclination to work on new
> features. I'd also like to propose some changes that are slightly
> backwards-incompatible, as well as some that mess with the internals
> to an extent that I'd feel better about doing it outside Boost
> itself, to make it easier for adventurous users to play with the new
> version without affecting people who depend on having an extremely
> stable library in Boost.
> To that end, I'm inclined to copy the library to somewhere else
> (possibly the boost sandbox, but more likely a separate site), work
> on it, produce some minor releases, and re-submit it to Boost for
> review. Perhaps the external site would continue on as the home of
> more fine-grained releases, or maybe we would fully reintegrate with
> Boost at that point (especially if Boost addresses some of its own
> project management and release control issues by that point, which I
> know is being discussed but to my knowledge doesn't really have a
> timeline yet).
> I am willing to take the lead on this project; I have a number of
> features that exist as extensions in the boost sandbox already that
> would work better if they could be more fully integrated into the
> Boost.Python core, and I think I have the necessary understanding of
> the full code base to coordinate things. I'd like to save a full
> discussion of what features a new version would include for another
> thread, but I am hoping other people on the list might volunteer
> some time to work on aspects they have coded up elsewhere - I know
> many such extensions exist.
> So I have a few questions for anyone who's paying attention:
> - For the original Boost.Python developers and current maintainers,
> and other people familiar with developing Boost libraries: do you
> have any preference on how to approach this? I don't want to step
> on any toes, especially toes attached to people who are responsible
> for the excellent library we already have.
> - For other Boost.Python experts on this list: do you have existing
> code or development time you'd like to contribute?
> Jim Bosch
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org <mailto:Cplusplus-sig at python.org>
> Cplusplus-sig mailing list
> Cplusplus-sig at python.org
More information about the Cplusplus-sig