On Sat, Jul 5, 2014 at 11:51 PM, Charles R Harris <charlesr.har...@gmail.com > wrote:
> > > > On Sat, Jul 5, 2014 at 8:28 AM, Matthew Brett <matthew.br...@gmail.com> > wrote: > >> On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau <courn...@gmail.com> >> wrote: >> > >> > >> > >> > 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. >> >> Why don't we wait until there is a significant problem with getting >> the Bento builds to work, and revisit then. >> >> > My feeling is that it is deceptive, as most folks who might use bento > won't know that some optimizations are missing from the result. > > David, I have pinged you a number of times about getting the numpy bento > build updated. The fact that bento builds numpy without failing is not the > same as bento building numpy in the best way. > Fair enough, let me look at it now, looks fairly trivial to fix David
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion