A Wednesday 03 February 2010 08:42:57 David Cournapeau escrigué: > > Yes, it means distributors of packages that depend on NumPy will have > > to recompile against the new version, and I can see why some might > > want to avoid that. Pushing what is really a distribution problem > > back to the NumPy package to manage separately is not the approach I > > would take. > > I don't think it is accurate to see ABI compatibility as a distribution > issue. It is mostly an orthogonal issue: it is true that ABI > incompatibility complicates distributions, but that's not the main issue. > > A more important scenario is as follows: let's assume we do allow > breaking the ABI every 1.X release, meaning that an ABI incompatible > change happens every ~ 6 months at the current pace (using the last 2-3 > years as history). Now, let's say I have a package foo which depends on > NumPy, and N other packages which also depend on NumPy. If any new > version of one of those package needs a new Numpy, you need to rebuild > everything. If those other packages depends on other libraries as well > which regularly break ABI, you get exponential breakage, the problem is > intractable. It is especially hard for packages which may not be easily > buildable - I think this is the case of many scientific experiments. > > I believe this is very detrimental for the whole scipy ecosystem: it is > only bearable because only NumPy is doing it. If everybody did the same, > it would be impossible to get anything stable.
I've been following this discussion with utter interest, and I also think that the arguments that favors a stable ABI in NumPy are *very* compelling. So +1 for *not* changing the ABI in .X releases. -- Francesc Alted _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
