On Thu, Aug 22, 2013 at 09:07:52PM -0700, Benedek Zoltan wrote:
> I've downloaded bootstrap.py and tried to initialize with system python:
>
> sabd1@sab /home/buildout $ wget
> http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py
FWIW that's an old version. You should be u
On 23 August 2013 05:47, Chris Barker - NOAA Federal
wrote:
> On Thu, Aug 22, 2013 at 8:17 PM, Nick Coghlan wrote:
>
> > numpy-1.7.1-cp27-cp22m-win32.whl
> > numpy-1.7.1-cp27-cp22m-win32-sse.whl
> > numpy-1.7.1-cp27-cp22m-win32-sse2.whl
> > numpy-1.7.1-cp27-cp22m-win32-sse3.whl
>
> I'm still conf
On 23 Aug, 2013, at 5:17, Nick Coghlan wrote:
>
> That said, I'm considering the idea of adding a "variant" field to the
> compatibility tags for wheel 1.1, along the lines of what Oscar
> Benjamin suggested earlier. By default, installers would only find
> wheels without a variant defined, but
On 23 Aug, 2013, at 0:52, Paul Moore wrote:
> On 22 August 2013 23:08, Chris Barker - NOAA Federal
> wrote:
> I want to give it a shot for OS-X -- no one seems to want to maintian
> bdist_mpkg, and it's time to move forward...
>
> My impression is that the architecture and "fat binary" stuff
On Aug 23, 2013, at 12:47 AM, Chris Barker - NOAA Federal
wrote:
> On Thu, Aug 22, 2013 at 8:17 PM, Nick Coghlan wrote:
>
>> numpy-1.7.1-cp27-cp22m-win32.whl
>> numpy-1.7.1-cp27-cp22m-win32-sse.whl
>> numpy-1.7.1-cp27-cp22m-win32-sse2.whl
>> numpy-1.7.1-cp27-cp22m-win32-sse3.whl
>
> I'm stil
On Thu, Aug 22, 2013 at 8:17 PM, Nick Coghlan wrote:
> numpy-1.7.1-cp27-cp22m-win32.whl
> numpy-1.7.1-cp27-cp22m-win32-sse.whl
> numpy-1.7.1-cp27-cp22m-win32-sse2.whl
> numpy-1.7.1-cp27-cp22m-win32-sse3.whl
I'm still confused -- how would "pip install numpy" know which of
these to install?
-Chr
Hi,
I've downloaded bootstrap.py and tried to initialize with system python:
sabd1@sab /home/buildout $ wget
http://svn.zope.org/*checkout*/zc.buildout/trunk/bootstrap/bootstrap.py
Warning: wildcards not supported in HTTP.
--20
On Aug 22, 2013, at 11:17 PM, Nick Coghlan wrote:
> - qualified yes for publication on PyPI (i.e. "there may still be
> rough edges, so don't be too surprised if this still has flaws at this
> point, especially on OS X and Linux")
PyPI won't even accept binary Wheels for Linux or OSX at the mom
On 23 August 2013 08:03, Chris Barker - NOAA Federal
wrote:
> On Thu, Aug 22, 2013 at 9:37 AM, Paul Moore wrote:
>
>> That is essentially possible now.
>>
>> 1. Go to Christoph Gohlke's website and download his bdist_wininst
>> installers for numpy and scipy.
>
>
>
> Exactly. And when all th
On Thu, Aug 22, 2013 at 3:52 PM, Paul Moore wrote:
> On 22 August 2013 23:08, Chris Barker - NOAA Federal
> My impression is that the architecture and "fat binary" stuff on OSX is the
> bit that may bite you.
exactly.
> I know little or nothing about OSX, but I'm sure if
> you try and report o
On 22 August 2013 23:08, Chris Barker - NOAA Federal
wrote:
> I want to give it a shot for OS-X -- no one seems to want to maintian
> bdist_mpkg, and it's time to move forward...
>
My impression is that the architecture and "fat binary" stuff on OSX is the
bit that may bite you. I know little or
On Thu, Aug 22, 2013 at 9:37 AM, Paul Moore wrote:
> That is essentially possible now.
>
> 1. Go to Christoph Gohlke's website and download his bdist_wininst
> installers for numpy and scipy.
Exactly. And when all this settles down, hopefully Christoph, and
others, will put up binary wheel
On Aug 22, 2013, at 6:08 PM, Chris Barker - NOAA Federal
wrote:
> but there is little point for a pure-python project. -- pip install
> works fine form source for those..
This isn't a true, a pure python wheel is still great. It's an order of
magnitude faster with less moving parts and static
> C extensions are not ready for use yet anywhere other than on Windows
> (Linux in particular has architecture/ABI questions to resolve)..
> Projects that use script wrappers probably shouldn't expect wheels to
> manage these seamlessly yet (things are still in flux in that area).
> "Advanced" fea
And sent form Paul Moore -- accidentally got off-list (my fault):
On 22 August 2013 18:47, Chris Barker - NOAA Federal
wrote:
> I'm still confused as to the state of all this -- are the tools ready
> for projects to start posting wheels so that pip can find them?
Basically, the answer is "maybe"
On 22 August 2013 16:33, Chris Barker - NOAA Federal
wrote:
> On Thu, Aug 22, 2013 at 6:52 AM, Oscar Benjamin
> wrote:
>
>> I'm pretty sure the current Windows installer just doesn't bother with
>> BLAS/LAPACK libraries. Maybe it will become possible to expose them
>> via a separate wheel-distrib
On 22 August 2013 16:33, Chris Barker - NOAA Federal
wrote:
> But maybe this is all too much to bite off for pip and wheels. If we
> could get to a state where "pip install numpy" and "pip install scipy"
> would do something reasonable, if not optimized, I think that would be
> great! And it's rea
On Thu, Aug 22, 2013 at 6:52 AM, Oscar Benjamin
wrote:
> I'm pretty sure the current Windows installer just doesn't bother with
> BLAS/LAPACK libraries. Maybe it will become possible to expose them
> via a separate wheel-distributed PyPI name one day.
Well, the rule of thumb with Windows binarie
On 22 August 2013 16:04, Nick Coghlan wrote:
> The next step is up to the pip folks - if they think adopting distlib
> wholesale makes sense for them, fine, I have no direct say in that. If
> they decide to make a "piplib" instead, to expose a public API for an
> updated version of pip's own infr
On 23 August 2013 00:19, Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>> When I made that suggestion, I misunderstood your plans for distlib.
>> If pip are only adopting a subset of it, they can't use the same name,
>> or people will get confused.
>
> I can certainly see that there are wa
Nick Coghlan gmail.com> writes:
> standard library is a mistake - the PyXML debacle shows us that. If
> the API is different (even if that means a strict subset), then it
> needs a different name.
I'm not really hung up about a specific name - what's in a name?
> It has nothing to do with code
On 22 August 2013 12:57, Vinay Sajip wrote:
>> I think that the installer ships variants for each architecture and
>> decides at install time which to place on the target system. If that's
>> the case then would it be possible for a wheel to ship all variants so
>> that a post-install script could
Disclaimer: everything I say below about pip is ultimately up to the
pip devs. I'm just pointing out what I think makes sense, and my
reading of Donald's comments means that I expect he would feel the
same way.
On 22 August 2013 17:22, Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>> What
On Thu, Aug 22, 2013 at 4:24 AM, Paul Moore wrote:
> On 21 August 2013 23:20, Vinay Sajip wrote:
>>
>> Nick Coghlan gmail.com> writes:
>>
>> > Um, the current wheel spec uses PEP 345 + setuptools metadata only. If
>> distlib is expecting PEP 426 metadata in wheel files, it is not compliant
>> wi
> -Original Message-
> From: Ronald Oussoren [mailto:ronaldousso...@mac.com]
> Sent: Thursday, August 22, 2013 12:21 PM
> To: Ferencik, Samuel: Markets (PRG)
> Cc: chris.bar...@noaa.gov; distutils-sig@python.org
> Subject: Re: [Distutils] distutils.util.get_platform() - Linux vs Windows
>
Oscar Benjamin gmail.com> writes:
> I think that the installer ships variants for each architecture and
> decides at install time which to place on the target system. If that's
> the case then would it be possible for a wheel to ship all variants so
> that a post-install script could sort it out
On 21 August 2013 22:22, Paul Moore wrote:
> On 21 August 2013 22:13, Nick Coghlan wrote:
>>
>> Wheel is a suitable replacement for bdist_wininst (although anything that
>> needs install hooks will have to wait for wheel 1.1, which will support
>> metadata 2.0). It's just not a replacement for wh
On 20 Aug, 2013, at 18:00, samuel.feren...@barclays.com wrote:
>> -Original Message-
>> From: Chris Barker - NOAA Federal [mailto:chris.bar...@noaa.gov]
>> Sent: Tuesday, August 20, 2013 5:47 PM
>> To: Ferencik, Samuel: Markets (PRG)
>> Cc: distutils-sig@python.org
>> Subject: Re: [Distu
On 20 Aug, 2013, at 8:15, samuel.feren...@barclays.com wrote:
>> -Original Message-
>> From: Chris Barker - NOAA Federal [mailto:chris.bar...@noaa.gov]
>> Sent: Monday, August 19, 2013 7:13 PM
>> To: Ferencik, Samuel: Markets (PRG)
>> Cc: distutils-sig@python.org
>> Subject: Re: [Distuti
Am 20.08.2013 19:39, schrieb PJ Eby:
I thought that at one point you (Thomas) had come up with a way to
load modules into memory from a zipfile without needing to extract
them. Was that you? If so, how did that work out?
To give a definite answer, after thinking it over:
It works, for quite
On 21 August 2013 23:20, Vinay Sajip wrote:
> Nick Coghlan gmail.com> writes:
>
> > Um, the current wheel spec uses PEP 345 + setuptools metadata only. If
> distlib is expecting PEP 426 metadata in wheel files, it is not compliant
> with
> the spec.
>
> I can certainly rectify that - I was possi
Nick Coghlan gmail.com> writes:
> However, the pydist.json that wheel currently writes is in the
> category of "arbitrary additional metadata in the dist-info
> directory", since the metadata 2.0 spec is still far from stable.
You can perhaps see why that could cause confusion - was that mention
Nick Coghlan gmail.com> writes:
> I previously thought distlib was going to be the repository for the
> agreed, stable, "this is going to happen" stuff. It's OK that I was
> wrong - I think you're right that somewhere is needed as an
> experimental location to show some of the *possibilities* of
33 matches
Mail list logo
