On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers <ralf.gomm...@gmail.com> wrote: > > On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith <n...@pobox.com> wrote: >> >> On 5 Jul 2014 09:23, "Ralf Gommers" <ralf.gomm...@gmail.com> wrote: >> > >> > On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau <courn...@gmail.com> >> > wrote: >> >> >> >> On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris >> >> <charlesr.har...@gmail.com> wrote: >> >>> >> >>> Ralf likes the speed of bento, but it is not currently maintained >> >> >> >> >> >> What exactly is not maintained ? >> > >> > >> > The issue is that Julian made some slightly nontrivial changes to >> > core/setup.py and didn't want to update core/bscript. No one else has taken >> > the time either to make those changes. That didn't bother me enough yet to >> > go fix it, because they're all optional features and using Bento builds >> > works just fine at the moment (and is part of the Travis CI test runs, so >> > it'll keep working). >> >> Perhaps a compromise would be to declare it officially unsupported and >> remove it from Travis CI, while leaving the files in place to be used on an >> at-your-own-risk basis? As long as it's in Travis, the default is that >> anyone who breaks it has to fix it. If it's not in Travis, then the default >> is that the people (person?) who use bento are responsible for keeping it >> working for their needs. > > -1 that just means that simple changes like adding a new extension will not > get made before PRs get merged, and bento support will be in a broken state > much more often.
Yes, and then the handful of people who care about this would fix it or not. Your -1 is attempting to veto other people's *not* paying attention to this build system. I... don't think -1's work that way :-( >> > I don't think the above is a good reason to remove Bento support. The >> > much faster builds alone are a good reason to keep it. And the assertion >> > that all numpy devs understand numpy.distutils is more than a little >> > questionable:) >> >> They surely don't. But thousands of people use setup.py, and one or two >> use bento. > > I'm getting a little tired of these assertions. It's clear that David and I > use it. A cursory search on Github reveals that Stefan, Fabian, Jonas and > @aksarkar do (or did) as well: > https://github.com/scipy/scipy/commit/74d823b3 > https://github.com/numpy/numpy/issues/2993 > https://github.com/numpy/numpy/pull/3606 > https://github.com/numpy/numpy/issues/3889 > For every user you can measure there's usually a number of users that you > don't hear about. I apologize for forgetting before that you do use Bento, but these patches you're finding don't really change the overall picture. Let's assume that there are 100 people using Bento, who would be slightly inconvenienced if they had to use setup.py instead, or got stuck patching the bento build themselves to keep it working. 100 is probably an order of magnitude too high, but whatever. OTOH numpy has almost 7 million downloads on PyPI+sf.net, of which approximately every one used setup.py one way or another, plus all the people get it from alternative channels like distros, which also AFAIK universally use setup.py. Software development is all about trade-offs. Time that numpy developers spend messing about with bento to benefit those hundred users is time that could instead be spent on improvements that benefit many orders of magnitudes more users. Why do you want us to spend our time producing x units of value when we could instead be producing 100*x units of value for the same effort? >> Yet supporting both requires twice as much energy and attention as >> supporting just one. > > That's of course not true. For most changes the differences in where and how > to update the build systems are small. Only for unusual changes like Julian > patches to make use of optional GCC features, Bento and distutils may > require very different changes. >> >> We've probably spent more person-hours talking about this, documenting the >> missing bscript bits, etc. than you've saved on those fast builds. > > Then maybe stop talking about it:) > > Besides the fast builds, which is only one example of why I like Bento > better, there's also the fundamental question of what we do with build tools > in the long term. It's clear that distutils is a dead end. All the PEPs > related to packaging move in the direction of supporting tools like Bento > better. If in the future we need significant new features in our build tool, > Bento is a much better base to build on than numpy.distutils. It's > unfortunate that at the moment there's no one that works on improving our > build situation, but that is what it is. Removing Bento support is a step in > the wrong direction imho. "We must do something! This is something!" Bento is pre-alpha software whose last upstream commit was in July 2013. It's own CI tests have been failing since Feb. 2013, almost a year and a half ago. Bento build support was added to numpy in early 2011, and 3.5 years later it still hasn't convinced most of the core team that it provides any value at all, yet it continues to take up time and attention. Maybe bento will revive and take over the new python packaging world! Maybe not. Maybe something else will. I don't see how our support for it will really affect these outcomes in any way. And I especially don't see why it's important to spend time *now* on keeping bento working, just in case it becomes useful *later*. If it proves valuable later, we can always fix our bscripts then. They won't dissolve irrecoverably out of history no matter what we do. -n -- Nathaniel J. Smith Postdoctoral researcher - Informatics - University of Edinburgh http://vorpus.org _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
