Toss me an invite too - I'm very interested in this, for all that I
havent' kibbitzed on the thread yet :)
On 9 October 2015 at 05:33, Nathaniel Smith wrote:
> On Oct 8, 2015 8:14 AM, "Nathaniel Smith" wrote:
>>
>> On Oct 7, 2015 2:58 PM, "Donald Stufft" wrote:
>> >
>> > On October 7, 2015 at 5
On Thu, 8 Oct 2015 22:05:16 +0200
Thomas Güttler wrote:
> This is a follow up to the thread "Where should I put tests when packaging
> python modules?"
>
> I have never used tox up to now. But reading the mails of the thread, it seems
> that tox is the current state of the art.
I don't see why
On Thursday, October 8, 2015, Thomas Güttler
wrote:
> This is a follow up to the thread "Where should I put tests when packaging
> python modules?"
>
> I have never used tox up to now. But reading the mails of the thread, it
> seems
> that tox is the current state of the art.
>
> This leads me to
This is a follow up to the thread "Where should I put tests when packaging
python modules?"
I have never used tox up to now. But reading the mails of the thread, it seems
that tox is the current state of the art.
This leads me to the conclusion that the sample project should use tox.
Any reason
On Oct 8, 2015 09:33, "Nathaniel Smith" wrote:
>
> On Oct 8, 2015 8:14 AM, "Nathaniel Smith" wrote:
> >
> > On Oct 7, 2015 2:58 PM, "Donald Stufft" wrote:
> > >
> > > On October 7, 2015 at 5:28:54 PM, Nathaniel Smith (n...@pobox.com)
wrote:
> > > > > Yeah, that's not a good long term solution --
On Oct 8, 2015 8:14 AM, "Nathaniel Smith" wrote:
>
> On Oct 7, 2015 2:58 PM, "Donald Stufft" wrote:
> >
> > On October 7, 2015 at 5:28:54 PM, Nathaniel Smith (n...@pobox.com) wrote:
> > > > Yeah, that's not a good long term solution -- it needs to be moved
> > > into the metadata (probably by cre
>
> But the different builds for the different configurations end up with
> different metadata. If I'm understanding right, the whole point of
> "source wheels" is that they have all the static metadata that pip
> needs in order to make decisions, and this has to match the resulting
> wheels -- rig
On Oct 7, 2015 2:58 PM, "Donald Stufft" wrote:
>
> On October 7, 2015 at 5:28:54 PM, Nathaniel Smith (n...@pobox.com) wrote:
> > > Yeah, that's not a good long term solution -- it needs to be moved
> > into the metadata (probably by creating an MKL wheel and then
> > making
> > the numpy wheel dep
On Oct 8, 2015 8:34 AM, "Ionel Cristian Mărieș" wrote:
>
>
> On Thu, Oct 8, 2015 at 4:01 PM, Donald Stufft wrote:
>>
>> One of the features in the original PEP was the ability to produce
multiple
>> different Wheels from the same source release much like how Debian does.
e.g.
>> numpy-1.0.newsdis
On Oct 8, 2015 9:23 AM, "Ionel Cristian Mărieș" wrote:
>
>
> On Thu, Oct 8, 2015 at 4:51 PM, Oscar Benjamin
wrote:
>>
>> It depends. If you're using numpy from pure Python code the difference
>> between mkl and otherblas is probably irrelevant. So in most cases
>> you'd want to be able to depend
On Thu, Oct 8, 2015 at 4:51 PM, Oscar Benjamin
wrote:
> It depends. If you're using numpy from pure Python code the difference
> between mkl and otherblas is probably irrelevant. So in most cases
> you'd want to be able to depend just on "numpy" but in some cases
> you'd need to be more specific.
On 8 October 2015 at 14:34, Ionel Cristian Mărieș wrote:
>
> On Thu, Oct 8, 2015 at 4:01 PM, Donald Stufft wrote:
>>
>> One of the features in the original PEP was the ability to produce
>> multiple
>> different Wheels from the same source release much like how Debian does.
>> e.g.
>> numpy-1.0.n
On Thu, Oct 8, 2015 at 4:01 PM, Donald Stufft wrote:
> One of the features in the original PEP was the ability to produce multiple
> different Wheels from the same source release much like how Debian does.
> e.g.
> numpy-1.0.newsdistthing could produce numpy-pyopenblas-12.6.whl and
> numpy-mkl-7.
On 8 October 2015 at 13:39, Oscar Benjamin wrote:
> On 8 October 2015 at 12:46, Paul Moore wrote:
>> On 8 October 2015 at 11:18, Oscar Benjamin
>> wrote:
>>>
>>> A concrete example would be whether or not the numpy source wheel
>>> depends on pyopenblas. Depending on how numpy is built the bina
On October 8, 2015 at 8:48:16 AM, Oscar Benjamin (oscar.j.benja...@gmail.com)
wrote:
> On 8 October 2015 at 13:05, Ionel Cristian Mărieș wrote:
> > On Thu, Oct 8, 2015 at 1:18 PM, Oscar Benjamin
> > wrote:
> >>
> >> I think this satisfies all of the requirements for static metadata and
> >> one-
On 8 October 2015 at 13:05, Ionel Cristian Mărieș wrote:
> On Thu, Oct 8, 2015 at 1:18 PM, Oscar Benjamin
> wrote:
>>
>> I think this satisfies all of the requirements for static metadata and
>> one-to-one correspondence of source wheels and binary wheels. If numpy
>> followed this then I imagine
On 8 October 2015 at 12:46, Paul Moore wrote:
> On 8 October 2015 at 11:18, Oscar Benjamin wrote:
>>
>> A concrete example would be whether or not the numpy source wheel
>> depends on pyopenblas. Depending on how numpy is built the binary
>> wheel may or may not depend on pyopenblas. It doesn't m
On Thu, Oct 8, 2015 at 1:18 PM, Oscar Benjamin
wrote:
> I think this satisfies all of the requirements for static metadata and
> one-to-one correspondence of source wheels and binary wheels. If numpy
> followed this then I imagine that there would be a single source wheel
> on PyPI corresponding
On 8 October 2015 at 11:18, Oscar Benjamin wrote:
> On 7 October 2015 at 22:41, Paul Moore wrote:
>> On 7 October 2015 at 22:28, Nathaniel Smith wrote:
>>> Maybe I have misunderstood: does it actually help pip at all to have
>>> static access to name and version, but not to anything else? I've b
On 7 October 2015 at 22:41, Paul Moore wrote:
> On 7 October 2015 at 22:28, Nathaniel Smith wrote:
>> Maybe I have misunderstood: does it actually help pip at all to have
>> static access to name and version, but not to anything else? I've been
>> assuming not, but I don't think anyone's pointed
20 matches
Mail list logo
