Re: [boost] RFC: Separating Boost.Python from Boost

Subject: Re: [boost] RFC: Separating Boost.Python from Boost
From: Stefan Seefeld (stefan_at_[hidden])
Date: 2015-05-29 23:55:28

On 29/05/15 11:19 PM, David Sankel wrote:
> The big thing I would need to see in order to support your proposal is an
> explanation of how it would handle dependency issues.

That's a good question. Ideally, Boost would be componentized to the
point where it would be easy to enumerate Boost.Python's dependencies
not on header files but on projects. But that's somewhat tangential to
the actual issues, so let's for now assume a simple split between
Boost.Python and the rest (or the subset of Boost that Boost.Python
requires).

>  Which version of the
> rest of Boost would Boost.Python require?

Ideally it wouldn't matter. In practice, there is of course the danger
that some change would be introduced to Boost (the remainder) that
breaks Boost.Python. This is a problem, well beyond Boost.Python, as
this means that such a change may affect other Boost users, too.
Unfortunately, so far there is absolutely no guarantee that any Boost
release N+1 is backward compatible with release N. I believe that it is
more than time for Boost to strive for backward compatibility, and to
make it very clear whenever any API-level incompatibilities are
introduced, so users can adjust.
With that knowledge, Boost.Python can address such changes using the
usual logic (configure / compile-time checks with conditional code).
As I mentioned again and again, such a process is extremely common in
the Free Software world when projects rely on third-party software
(mostly libraries), and need to adjust to API changes.

>  Is there any chance that a Boost
> upgrade would break the current release of Boost.Python?

Sure, but I think it's Boost's (the remainder's) responsibility to
document whenever such a change is introduced, to allow Boost.Python
developer's (as well as any Boost users who may encounter such a change,
for that matter !) to adjust.

>  If other libraries
> follow suit, how would the dependency issues effect them? As a user of
> Boost, what extra steps or effort would be needed to deal with the new
> dependency problem? (One benefit of the current lock-step release model is
> that we get an implicit guarantee that all the boost libraries in a
> particular release are compatible with each other).

Yes, and I agree that is a big convenience. Whenever a project 'A'
depends on libraries 'B' and 'C' (say), it needs to run tests to
determine that a particular range of versions of 'B' and 'C' work with
'A' (whether that requires any conditional logic in 'A' or not), and
document that properly (as well as encode that into the build system to
flag attempts to build against incompatible versions of 'B' and 'C').

Again, the real issue here is quite independent of my attempt to
decouple Boost.Python from the rest of Boost: It's that as far as Boost
is concerned, there has never been any explicit or implied guarantee
that subsequent Boost releases are API compatible (or even ABI
compatible !). I think it's time to rethink that.

> Thanks in advance for your thoughts.

Thanks for your encouraging feedback !

        Stefan

-- 
      ...ich hab' noch einen Koffer in Berlin...