Remove bento from numpy

classic Classic list List threaded Threaded
24 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Remove bento from numpy

Charles R Harris
Ralf likes the speed of bento, but it is not currently maintained and does not properly build numpy with all the optimizations added by Julian. I find the usual setup.py method fast enough and it has the advantage that all the numpy developers can deal with it.

Thoughts?

Chuck

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

David Cournapeau



On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris <[hidden email]> wrote:
Ralf likes the speed of bento, but it is not currently maintained

What exactly is not maintained ?

David

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

ralfgommers



On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau <[hidden email]> wrote:



On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris <[hidden email]> 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).

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:)

Ralf

 

David

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion



_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

David Cournapeau



On Sat, Jul 5, 2014 at 5:23 PM, Ralf Gommers <[hidden email]> wrote:



On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau <[hidden email]> wrote:



On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris <[hidden email]> 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).

What are those changes ?

David

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

ralfgommers



On Sat, Jul 5, 2014 at 10:44 AM, David Cournapeau <[hidden email]> wrote:



On Sat, Jul 5, 2014 at 5:23 PM, Ralf Gommers <[hidden email]> wrote:



On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau <[hidden email]> wrote:



On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris <[hidden email]> 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).

What are those changes?

Comment in bscript:

    # TODO: add OPTIONAL_HEADERS, OPTIONAL_INTRINSICS and
    # OPTIONAL_GCC_ATTRIBUTES (see setup.py and gh-3766).  These are
    # performance optimizations for GCC.

Plus the changes in https://github.com/numpy/numpy/pull/4692, that apparently weren't documented in bscript as TODO.

Ralf


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

Julian Taylor-3
On 05.07.2014 11:02, Ralf Gommers wrote:

>
>
>
> On Sat, Jul 5, 2014 at 10:44 AM, David Cournapeau <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>
>
>
>     On Sat, Jul 5, 2014 at 5:23 PM, Ralf Gommers <[hidden email]
>     <mailto:[hidden email]>> wrote:
>
>
>
>
>         On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau
>         <[hidden email] <mailto:[hidden email]>> wrote:
>
>
>
>
>             On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris
>             <[hidden email]
>             <mailto:[hidden email]>> 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).
>
>
>     What are those changes?
>
>
> Comment in bscript:
>
>     # TODO: add OPTIONAL_HEADERS, OPTIONAL_INTRINSICS and
>     # OPTIONAL_GCC_ATTRIBUTES (see setup.py and gh-3766).  These are
>     # performance optimizations for GCC.
>
> Plus the changes in https://github.com/numpy/numpy/pull/4692, that
> apparently weren't documented in bscript as TODO.
>

+ bento builds in debug mode which is could be slower because I
sprinkled asserts in lots of places
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

Nathaniel Smith
In reply to this post by ralfgommers

On 5 Jul 2014 09:23, "Ralf Gommers" <[hidden email]> wrote:
>
> On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau <[hidden email]> wrote:
>>
>> On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris <[hidden email]> 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.

> 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. Yet supporting both requires twice as much energy and attention as supporting just one. We've probably spent more person-hours talking about this, documenting the missing bscript bits, etc. than you've saved on those fast builds.

-n


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

ralfgommers



On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith <[hidden email]> wrote:

On 5 Jul 2014 09:23, "Ralf Gommers" <[hidden email]> wrote:
>
> On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau <[hidden email]> wrote:
>>
>> On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris <[hidden email]> 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.

> 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.

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.

Ralf


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

Nathaniel Smith
On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers <[hidden email]> wrote:

>
> On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith <[hidden email]> wrote:
>>
>> On 5 Jul 2014 09:23, "Ralf Gommers" <[hidden email]> wrote:
>> >
>> > On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau <[hidden email]>
>> > wrote:
>> >>
>> >> On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris
>> >> <[hidden email]> 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
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

David Cournapeau



On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith <[hidden email]> wrote:
On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers <[hidden email]> wrote:
>
> On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith <[hidden email]> wrote:
>>
>> On 5 Jul 2014 09:23, "Ralf Gommers" <[hidden email]> wrote:
>> >
>> > On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau <[hidden email]>
>> > wrote:
>> >>
>> >> On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris
>> >> <[hidden email]> 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
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

Matthew Brett
On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau <[hidden email]> wrote:

>
>
>
> On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith <[hidden email]> wrote:
>>
>> On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers <[hidden email]>
>> wrote:
>> >
>> > On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith <[hidden email]> wrote:
>> >>
>> >> On 5 Jul 2014 09:23, "Ralf Gommers" <[hidden email]> wrote:
>> >> >
>> >> > On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau
>> >> > <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris
>> >> >> <[hidden email]> 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.

Cheers,

Matthew
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

Charles R Harris



On Sat, Jul 5, 2014 at 8:28 AM, Matthew Brett <[hidden email]> wrote:
On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau <[hidden email]> wrote:
>
>
>
> On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith <[hidden email]> wrote:
>>
>> On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers <[hidden email]>
>> wrote:
>> >
>> > On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith <[hidden email]> wrote:
>> >>
>> >> On 5 Jul 2014 09:23, "Ralf Gommers" <[hidden email]> wrote:
>> >> >
>> >> > On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau
>> >> > <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris
>> >> >> <[hidden email]> 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
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

David Cournapeau



On Sat, Jul 5, 2014 at 11:51 PM, Charles R Harris <[hidden email]> wrote:



On Sat, Jul 5, 2014 at 8:28 AM, Matthew Brett <[hidden email]> wrote:
On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau <[hidden email]> wrote:
>
>
>
> On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith <[hidden email]> wrote:
>>
>> On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers <[hidden email]>
>> wrote:
>> >
>> > On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith <[hidden email]> wrote:
>> >>
>> >> On 5 Jul 2014 09:23, "Ralf Gommers" <[hidden email]> wrote:
>> >> >
>> >> > On Sat, Jul 5, 2014 at 10:13 AM, David Cournapeau
>> >> > <[hidden email]>
>> >> > wrote:
>> >> >>
>> >> >> On Sat, Jul 5, 2014 at 11:25 AM, Charles R Harris
>> >> >> <[hidden email]> 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
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

Nathaniel Smith
In reply to this post by David Cournapeau
On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau <[hidden email]> wrote:

>
> On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith <[hidden email]> wrote:
>>
>> 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.

My suggestion was that we should drop the rule that a patch has to
keep bento working to be merged. We're talking about future breakages
and future effort. The fact that it's working now doesn't say anything
about whether it's worth continuing to invest time in it.

--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

David Cournapeau
The efforts are on average less demanding than this discussion. We are talking about adding entries to a list in most cases...

Also, while adding the optimization support for bento, I've noticed that a lot of the related distutils code is broken, and does not work as expected on at least OS X + clang.

David


On Sun, Jul 6, 2014 at 1:38 AM, Nathaniel Smith <[hidden email]> wrote:
On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau <[hidden email]> wrote:
>
> On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith <[hidden email]> wrote:
>>
>> 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.

My suggestion was that we should drop the rule that a patch has to
keep bento working to be merged. We're talking about future breakages
and future effort. The fact that it's working now doesn't say anything
about whether it's worth continuing to invest time in it.

--
Nathaniel J. Smith
Postdoctoral researcher - Informatics - University of Edinburgh
http://vorpus.org
_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

Julian Taylor-3
On 05.07.2014 18:40, David Cournapeau wrote:
> The efforts are on average less demanding than this discussion. We are
> talking about adding entries to a list in most cases...
>
> Also, while adding the optimization support for bento, I've noticed that
> a lot of the related distutils code is broken, and does not work as
> expected on at least OS X + clang.

It just spits out a lot of warnings but they are harmless.
We could remove them by using with -Werror=attribute for the conftests
if it really bothers someone.
Or do you mean something else?

>
> David
>
>
> On Sun, Jul 6, 2014 at 1:38 AM, Nathaniel Smith <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >
>     > On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >>
>     >> 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.
>
>     My suggestion was that we should drop the rule that a patch has to
>     keep bento working to be merged. We're talking about future breakages
>     and future effort. The fact that it's working now doesn't say anything
>     about whether it's worth continuing to invest time in it.
>
>     --
>     Nathaniel J. Smith
>     Postdoctoral researcher - Informatics - University of Edinburgh
>     http://vorpus.org
>     _______________________________________________
>     NumPy-Discussion mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

David Cournapeau



On Sun, Jul 6, 2014 at 1:55 AM, Julian Taylor <[hidden email]> wrote:
On 05.07.2014 18:40, David Cournapeau wrote:
> The efforts are on average less demanding than this discussion. We are
> talking about adding entries to a list in most cases...
>
> Also, while adding the optimization support for bento, I've noticed that
> a lot of the related distutils code is broken, and does not work as
> expected on at least OS X + clang.

It just spits out a lot of warnings but they are harmless.

Adding lots of warnings are not harmless as they render the compiler warning system near useless (too many false alarms).

I will fix the checks for both distutils and bento (using the autoconf macros setup, which should be more reliable than what we use for builtin and __attribute__-related checks)

David
 
We could remove them by using with -Werror=attribute for the conftests
if it really bothers someone.
Or do you mean something else?

>
> David
>
>
> On Sun, Jul 6, 2014 at 1:38 AM, Nathaniel Smith <[hidden email]
> <mailto:[hidden email]>> wrote:
>
>     On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >
>     > On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith <[hidden email]
>     <mailto:[hidden email]>> wrote:
>     >>
>     >> 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.
>
>     My suggestion was that we should drop the rule that a patch has to
>     keep bento working to be merged. We're talking about future breakages
>     and future effort. The fact that it's working now doesn't say anything
>     about whether it's worth continuing to invest time in it.
>
>     --
>     Nathaniel J. Smith
>     Postdoctoral researcher - Informatics - University of Edinburgh
>     http://vorpus.org
>     _______________________________________________
>     NumPy-Discussion mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

Julian Taylor-3
On 05.07.2014 19:11, David Cournapeau wrote:

> On Sun, Jul 6, 2014 at 1:55 AM, Julian Taylor
> <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     On 05.07.2014 18:40, David Cournapeau wrote:
>     > The efforts are on average less demanding than this discussion. We are
>     > talking about adding entries to a list in most cases...
>     >
>     > Also, while adding the optimization support for bento, I've
>     noticed that
>     > a lot of the related distutils code is broken, and does not work as
>     > expected on at least OS X + clang.
>
>     It just spits out a lot of warnings but they are harmless.
>
>
> Adding lots of warnings are not harmless as they render the compiler
> warning system near useless (too many false alarms).
>

true but until now we haven't received a single complaint nor fixes so
probably not many developers are actually using macs/clang to work on
numpy C code.
But I do agree its bad and I have fixing that on my todo list, I didn't
get around to it yet.

> I will fix the checks for both distutils and bento (using the autoconf
> macros setup, which should be more reliable than what we use for builtin
> and __attribute__-related checks)
>
> David
>  
>
>     We could remove them by using with -Werror=attribute for the conftests
>     if it really bothers someone.
>     Or do you mean something else?
>
>     >
>     > David
>     >
>     >
>     > On Sun, Jul 6, 2014 at 1:38 AM, Nathaniel Smith <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau
>     <[hidden email] <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >     >
>     >     > On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith
>     <[hidden email] <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >     >>
>     >     >> 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.
>     >
>     >     My suggestion was that we should drop the rule that a patch has to
>     >     keep bento working to be merged. We're talking about future
>     breakages
>     >     and future effort. The fact that it's working now doesn't say
>     anything
>     >     about whether it's worth continuing to invest time in it.
>     >
>     >     --
>     >     Nathaniel J. Smith
>     >     Postdoctoral researcher - Informatics - University of Edinburgh
>     >     http://vorpus.org
>     >     _______________________________________________
>     >     NumPy-Discussion mailing list
>     >     [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >     http://mail.scipy.org/mailman/listinfo/numpy-discussion
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > NumPy-Discussion mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>     >
>
>     _______________________________________________
>     NumPy-Discussion mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

David Cournapeau



On Sun, Jul 6, 2014 at 2:24 AM, Julian Taylor <[hidden email]> wrote:
On 05.07.2014 19:11, David Cournapeau wrote:
> On Sun, Jul 6, 2014 at 1:55 AM, Julian Taylor
> <[hidden email] <mailto:[hidden email]>>
> wrote:
>
>     On 05.07.2014 18:40, David Cournapeau wrote:
>     > The efforts are on average less demanding than this discussion. We are
>     > talking about adding entries to a list in most cases...
>     >
>     > Also, while adding the optimization support for bento, I've
>     noticed that
>     > a lot of the related distutils code is broken, and does not work as
>     > expected on at least OS X + clang.
>
>     It just spits out a lot of warnings but they are harmless.
>
>
> Adding lots of warnings are not harmless as they render the compiler
> warning system near useless (too many false alarms).
>

true but until now we haven't received a single complaint nor fixes so
probably not many developers are actually using macs/clang to work on
numpy C code.

Not many people are working on numpy C code period :)

FWIW, clang is now the standard OS X compiler since Maverick (Apple in all its wisdom made gcc an alias to clang...).

David
 
But I do agree its bad and I have fixing that on my todo list, I didn't
get around to it yet.

> I will fix the checks for both distutils and bento (using the autoconf
> macros setup, which should be more reliable than what we use for builtin
> and __attribute__-related checks)
>
> David
>
>
>     We could remove them by using with -Werror=attribute for the conftests
>     if it really bothers someone.
>     Or do you mean something else?
>
>     >
>     > David
>     >
>     >
>     > On Sun, Jul 6, 2014 at 1:38 AM, Nathaniel Smith <[hidden email]
>     <mailto:[hidden email]>
>     > <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >
>     >     On Sat, Jul 5, 2014 at 3:21 PM, David Cournapeau
>     <[hidden email] <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >     >
>     >     > On Sat, Jul 5, 2014 at 11:17 PM, Nathaniel Smith
>     <[hidden email] <mailto:[hidden email]>
>     >     <mailto:[hidden email] <mailto:[hidden email]>>> wrote:
>     >     >>
>     >     >> 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.
>     >
>     >     My suggestion was that we should drop the rule that a patch has to
>     >     keep bento working to be merged. We're talking about future
>     breakages
>     >     and future effort. The fact that it's working now doesn't say
>     anything
>     >     about whether it's worth continuing to invest time in it.
>     >
>     >     --
>     >     Nathaniel J. Smith
>     >     Postdoctoral researcher - Informatics - University of Edinburgh
>     >     http://vorpus.org
>     >     _______________________________________________
>     >     NumPy-Discussion mailing list
>     >     [hidden email] <mailto:[hidden email]>
>     <mailto:[hidden email] <mailto:[hidden email]>>
>     >     http://mail.scipy.org/mailman/listinfo/numpy-discussion
>     >
>     >
>     >
>     >
>     > _______________________________________________
>     > NumPy-Discussion mailing list
>     > [hidden email] <mailto:[hidden email]>
>     > http://mail.scipy.org/mailman/listinfo/numpy-discussion
>     >
>
>     _______________________________________________
>     NumPy-Discussion mailing list
>     [hidden email] <mailto:[hidden email]>
>     http://mail.scipy.org/mailman/listinfo/numpy-discussion
>
>
>
>
> _______________________________________________
> NumPy-Discussion mailing list
> [hidden email]
> http://mail.scipy.org/mailman/listinfo/numpy-discussion
>

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Remove bento from numpy

ralfgommers
In reply to this post by Nathaniel Smith



On Sat, Jul 5, 2014 at 4:17 PM, Nathaniel Smith <[hidden email]> wrote:
On Sat, Jul 5, 2014 at 2:32 PM, Ralf Gommers <[hidden email]> wrote:
>
> On Sat, Jul 5, 2014 at 1:54 PM, Nathaniel Smith <[hidden email]> wrote:
>>
>> On 5 Jul 2014 09:23, "Ralf Gommers" <[hidden email]> wrote:
>> 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.

What next, we give Alan Isaac commit rights and then it's OK to break numpy.matrix when that's convenient?
 
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
:-(

You're proposing it'll be OK for others to break stuff that the people before them put quite some effort into implementing. I damn well have the right to give that a -1.

David is fixing the few existing problems now, so there should be zero issues here. You're deliberately mischaracterizing the situation (pre-alpha, lot of effort, etc.), so I'm not going to bother responding to the rest, I'm annoyed enough as is.

Ralf

P.S. if anyone wants to spend some productive energy on the build situation, MSVC 2010 support for Python 3.x would be nice: https://github.com/numpy/numpy/issues/4245


_______________________________________________
NumPy-Discussion mailing list
[hidden email]
http://mail.scipy.org/mailman/listinfo/numpy-discussion
12