On 6 December 2013 17:10, Thomas Heller thel...@ctypes.org wrote:
Am 06.12.2013 06:47, schrieb Nick Coghlan:
Hmm, I just had an idea for how to do the runtime selection thing. It
actually shouldn't be that hard, so long as the numpy folks are OK
with a bit of __path__ manipulation in package
On 6 December 2013 17:21, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Fri, Dec 6, 2013 at 6:47 AM, Nick Coghlan ncogh...@gmail.com wrote:
With that approach, the existing wheel model would work (no need for a
variant system), and numpy installations could be freely moved between
machines (or
How does conda handle SSE vs SSE2 vs SSE3? I’m digging through it’s
source code and just installed numpy with it and I can’t seem to find any
handling of that?
On Dec 6, 2013, at 7:33 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 6 December 2013 17:21, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Fri, Dec 6, 2013 at 5:47 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 6 December 2013 11:52, Donald Stufft don...@stufft.io wrote:
On Dec 5, 2013, at 8:48 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
What would really be best is run-time selection of the appropriate
On Fri, Dec 6, 2013 at 12:44 PM, Donald Stufft don...@stufft.io wrote:
How does conda handle SSE vs SSE2 vs SSE3? I’m digging through it’s
source code and just installed numpy with it and I can’t seem to find any
handling of that?
I can't speak for conda, but @enthought, we solve it by using
Am 06.12.2013 13:22, schrieb Nick Coghlan:
On 6 December 2013 17:10, Thomas Heller thel...@ctypes.org wrote:
Am 06.12.2013 06:47, schrieb Nick Coghlan:
Hmm, I just had an idea for how to do the runtime selection thing. It
actually shouldn't be that hard, so long as the numpy folks are OK
with
On 6 December 2013 13:06, David Cournapeau courn...@gmail.com wrote:
As Ralf, I think it is overkill. The problem of SSE vs non SSE is because of
one library, ATLAS, which as IMO the design flaw of being arch specific. I
always hoped we could get away from this when I built those special
On 4 December 2013 21:10, Nick Coghlan ncogh...@gmail.com wrote:
== Regarding conda ==
In terms of providing an answer to the question Where does conda fit
in the scheme of packaging tools?, my conclusion from the thread is
that once a couple of security related issues are fixed (think PyPI
On 6 December 2013 13:54, Nick Coghlan ncogh...@gmail.com wrote:
On 4 December 2013 21:10, Nick Coghlan ncogh...@gmail.com wrote:
== Regarding conda ==
In terms of providing an answer to the question Where does conda fit
in the scheme of packaging tools?, my conclusion from the thread is
On 7 December 2013 00:05, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 6 December 2013 13:54, Nick Coghlan ncogh...@gmail.com wrote:
On 4 December 2013 21:10, Nick Coghlan ncogh...@gmail.com wrote:
I think this is important enough to warrant a NumPy and the
Scientific Python stack
On Thu, Dec 5, 2013 at 11:21 PM, Ralf Gommers ralf.gomm...@gmail.comwrote:
Hmm, taking a compile flag and encoding it in the package layout seems
like a fundamentally wrong approach.
well, it's pretty ugly hack, but sometimes an ugly hack that does the job
is better than nothing.
IIUC, the
On Fri, Dec 6, 2013 at 1:33 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 6 December 2013 17:21, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Fri, Dec 6, 2013 at 6:47 AM, Nick Coghlan ncogh...@gmail.com wrote:
With that approach, the existing wheel model would work (no need for a
variant
On Fri, Dec 6, 2013 at 2:48 PM, Oscar Benjamin
oscar.j.benja...@gmail.comwrote:
On 6 December 2013 13:06, David Cournapeau courn...@gmail.com wrote:
As Ralf, I think it is overkill. The problem of SSE vs non SSE is
because of
one library, ATLAS, which as IMO the design flaw of being arch
On Fri, Dec 6, 2013 at 6:22 AM, Nick Coghlan ncogh...@gmail.com wrote:
I created a draft of this new section at
https://bitbucket.org/pypa/python-packaging-user-guide/pull-request/12/recommendations-for-numpy-et-al/diff
looks good, thanks!
ONe note:
In particular, bootstrapping conda
On Fri, Dec 6, 2013 at 4:33 AM, Nick Coghlan ncogh...@gmail.com wrote:
In the absence of the perfect solution (i.e. picking the right variant
out of no SSE, SSE2, SSE3 automatically), would it be a reasonable
compromise to standardise on SSE2 as lowest acceptable common
denominator?
+1
On Fri, Dec 6, 2013 at 5:50 PM, Chris Barker chris.bar...@noaa.gov wrote:
On Fri, Dec 6, 2013 at 5:06 AM, David Cournapeau courn...@gmail.comwrote:
As Ralf, I think it is overkill. The problem of SSE vs non SSE is because
of one library, ATLAS, which as IMO the design flaw of being arch
On Fri, Dec 6, 2013 at 5:06 AM, David Cournapeau courn...@gmail.com wrote:
As Ralf, I think it is overkill. The problem of SSE vs non SSE is because
of one library, ATLAS, which as IMO the design flaw of being arch specific.
yup -- really designed for the end user to built it themselves
On Fri, Dec 6, 2013 at 5:16 AM, Thomas Heller thel...@ctypes.org wrote:
Am 06.12.2013 13:22, schrieb Nick Coghlan:
Manipulation of __path__ at runtime usually makes it harder for
modulefinder to find all the required modules.
Not usually, always. That's why
We use setuptools for our library. I'm trying to figure out a way to upload
an sdist and an egg to PyPI without having to put my PyPI credentials in a
file. Please let me know if this is not the right mailing list for this
question.
Our setup is that the entire team has access to the source
On 7 December 2013 03:44, Chris Barker chris.bar...@noaa.gov wrote:
On Fri, Dec 6, 2013 at 6:22 AM, Nick Coghlan ncogh...@gmail.com wrote:
I created a draft of this new section at
https://bitbucket.org/pypa/python-packaging-user-guide/pull-request/12/recommendations-for-numpy-et-al/diff
20 matches
Mail list logo
