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. Chuck
_______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@scipy.org http://mail.scipy.org/mailman/listinfo/numpy-discussion
