On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith <n...@pobox.com> wrote:
> 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*. But it is working right now, so that argument is moot. David
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
