On 3 December 2013 22:18, Chris Barker chris.bar...@noaa.gov wrote:
Looks like the conda stack is built around msvcr90, whereas python.org
Python 3.3 is built around msvcr100.
So conda is not interoperable *at all* with standard python.org Python
3.3 on Windows :-(
again, Anaconda the
On 4 December 2013 07:40, Ralf Gommers ralf.gomm...@gmail.com wrote:
I’m not sure what the diff between the current state and what
they need to be are but if someone spells it out (I’ve only just skimmed
your last email so perhaps it’s contained in that!) I’ll do the arguing
for it. I
just
On 4 December 2013 08:13, Paul Moore p.f.mo...@gmail.com wrote:
If this is too difficult at the moment, an easier (but much less important
one) would be to get the result of ``paver bdist_wininst_simple`` as a
wheel.
That I will certainly look into. Simple answer is wheel convert
wininst.
On 4 December 2013 07:40, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Wed, Dec 4, 2013 at 1:54 AM, Donald Stufft don...@stufft.io wrote:
I’d love to get Wheels to the point they are more suitable then they are
for SciPy stuff,
That would indeed be a good step forward. I'm interested to try
There was some really good feedback in the binary dependency thread,
but it ended up going off on a few different tangents. Rather than
expecting people to read the whole thing, I figured I'd try to come up
with a summary of where it has gone so far, and where we might want to
take it from here.
On 4 December 2013 20:41, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 4 December 2013 07:40, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Wed, Dec 4, 2013 at 1:54 AM, Donald Stufft don...@stufft.io wrote:
I’d love to get Wheels to the point they are more suitable then they are
for
Am 04.12.2013 11:41, schrieb Oscar Benjamin:
On 4 December 2013 07:40, Ralf Gommers ralf.gomm...@gmail.com wrote:
How do I package those three builds into wheels and get the right one
installed by ``pip install numpy``?
This was discussed previously on this list:
On 4 December 2013 12:10, Nick Coghlan ncogh...@gmail.com wrote:
On 4 December 2013 20:41, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
Another possibility is that the pip/wheel/PyPI/metadata system can be
changed to allow a variant field for wheels/sdists. This was also
suggested in the
On Wed, Dec 4, 2013 at 6:10 AM, Nick Coghlan ncogh...@gmail.com wrote:
There was some really good feedback in the binary dependency thread,
but it ended up going off on a few different tangents. Rather than
expecting people to read the whole thing, I figured I'd try to come up
with a summary
I'm trying to mirror the simple index (just the index, not the
referenced files) in order to do some queries on package availability.
I was planning on doing a simple wget --timestamping --recursive
--level=1 but when I do, everything seems to be downloaded each time.
Does PyPI not set the last
- a richer platform tagging mechanism (which we need for *nix systems
anyway)
- a way to ensure internal consistency of the installed *builds* in an
environment, not just the abstract dependencies
I've opened a wheel format definition issue for the first problem:
pip install --tag=continuum-super-science-stack_x86_64 --index-url=
http://continuum/wheels numpy
CORRECTION: drop the _x86_64. that wouldn't be needed with properly
packaged wheels.
___
Distutils-SIG maillist - Distutils-SIG@python.org
On Wed, Dec 4, 2013 at 5:05 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
Ralf,
Great to have you on this thread!
Note: supporting variants on one way or another is a great idea, but for
right now, maybe we can get pretty far without it.
There are options for serious scipy
On Wed, Dec 4, 2013 at 9:13 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 4 December 2013 07:40, Ralf Gommers ralf.gomm...@gmail.com wrote:
I’m not sure what the diff between the current state and what
they need to be are but if someone spells it out (I’ve only just skimmed
your last email
On Wed, Dec 4, 2013 at 11:41 AM, Oscar Benjamin
oscar.j.benja...@gmail.comwrote:
On 4 December 2013 07:40, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Wed, Dec 4, 2013 at 1:54 AM, Donald Stufft don...@stufft.io wrote:
I’d love to get Wheels to the point they are more suitable then they
On 4 December 2013 21:13, Ralf Gommers ralf.gomm...@gmail.com wrote:
Besides the issues you mention, the problem is that it creates a single
point of failure. I really appreciate everything Christoph does, but it's
not appropriate as the default way to provide binary releases for a large
On Wed, Dec 4, 2013 at 10:59 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 4 December 2013 21:13, Ralf Gommers ralf.gomm...@gmail.com wrote:
Besides the issues you mention, the problem is that it creates a single
point of failure. I really appreciate everything Christoph does, but it's
not
On 5 Dec 2013 07:29, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Wed, Dec 4, 2013 at 11:41 AM, Oscar Benjamin
oscar.j.benja...@gmail.com wrote:
On 4 December 2013 07:40, Ralf Gommers ralf.gomm...@gmail.com wrote:
On Wed, Dec 4, 2013 at 1:54 AM, Donald Stufft don...@stufft.io wrote:
ok, but could/would the pip/wheel toolchain ever expand itself to handle
delivery of external dependencies (like qt, tk, and numpy's fortran
stuff).
fortran stuff is pretty poorly defined -- I'm not sure we'd ever want
pip to install a fortran compiler for you
to be very literal,
On Wed, Dec 4, 2013 at 12:56 PM, Ralf Gommers ralf.gomm...@gmail.comwrote:
The problem is explaining to people what they want - no one reads docs
before grabbing a binary.
right -- so we want a default pip install install that will work for most
people. And I think works for most people is
On Thu, Dec 5, 2013 at 1:09 AM, Chris Barker chris.bar...@noaa.gov wrote:
On Wed, Dec 4, 2013 at 12:56 PM, Ralf Gommers ralf.gomm...@gmail.comwrote:
The problem is explaining to people what they want - no one reads docs
before grabbing a binary.
right -- so we want a default pip install
21 matches
Mail list logo
