Re: [Distutils] Platform tags for OS X binary wheels

Hi, > Trust me on that :-) That's not really the point -- I use both conda and pip, maintain https://github.com/omnia-md/conda-recipes, and have made multiple upstream contributions to conda-build. The point of this thread, from my perspective, was to confirm that there's a small bug in pip in

Re: [Distutils] Platform tags for OS X binary wheels

I'm using the Python from the Miniconda installer with py35 released last week. What does the python.org installer build for 10.6+ return for `distutils.util.get_platform()`? -Robert On Fri, Nov 6, 2015 at 2:50 PM, Ned Deily wrote: > In article >

Re: [Distutils] [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

> While I understand what you're trying to achieve (and I'm in favour, > in general) it should be remembered that pip's core goal is installing > packages - not being a component of a development workflow. Yes -- clear separation of concerns here! So what IS supposed to be used in the

Re: [Distutils] Platform tags for OS X binary wheels

In article , Robert McGibbon wrote: > I'm using the Python from the Miniconda installer with py35 released last > week. > > What does the python.org installer build for 10.6+ return for >

Re: [Distutils] The future of invoking pip

On Fri, Nov 6, 2015 at 4:52 AM, Glyph Lefkowitz wrote: > > Rather than trying to figure out what the "right" way for users to invoke > `pip´ to begin with is, why not just have Pip start providing more > *information* about potential problems when you invoke it? > > If

Re: [Distutils] Platform tags for OS X binary wheels

In article , Robert McGibbon wrote: > I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it > proceeds to download and compile the tarball from PyPI from source (very > slow). I see,

Re: [Distutils] Platform tags for OS X binary wheels

On Sat, Nov 7, 2015 at 1:04 AM, Chris Barker - NOAA Federal < chris.bar...@noaa.gov> wrote: > On Nov 6, 2015, at 3:57 PM, Robert McGibbon wrote: > > I'm using the Python from the Miniconda installer with py35 released last > week. > > > Then you should not expect it to be

Re: [Distutils] Platform tags for OS X binary wheels

On Nov 6, 2015, at 3:57 PM, Robert McGibbon wrote: I'm using the Python from the Miniconda installer with py35 released last week. Then you should not expect it to be able to find compatible binary wheels on PyPi. Pretty much the entire point of conda is to support Numpy

Re: [Distutils] New PEP : dependency specification

On Thu, Nov 5, 2015 at 7:32 PM, Robert Collins wrote: > Since we ended up with a hard dependency on this for the bootstrap > thing (regardless of 'smaller step' or not) - I've broken this out of > PEP 426, made it an encoding of the current status quo rather than an >

Re: [Distutils] The future of invoking pip

On 6 November 2015 at 03:52, Glyph Lefkowitz wrote: > If you invoke 'pip[X.Y]' and it matches 'python -m pip' in your current > virtualenv, don't say anything; similarly if you invoke 'python -m pip' and > 'which pip' matches. But if there's a mismatch, pip can print

Re: [Distutils] The future of invoking pip

On 5 November 2015 at 22:59, Donald Stufft wrote: > I think we could integrate with py on Windows somehow so that we use the same > lookup semantics as py does. I don't know enough about Windows and py.exe to > know what exactly those are. Hmm, I'm reluctant to get into

Re: [Distutils] New PEP : dependency specification

On 7 November 2015 at 07:42, Marcus Smith wrote: >> >> >> No - it specifies the serialisation format for >> names/specifiers/extras/markers that is in common use, but doesn't >> specify a programming API. It is intended as an interop building >> block, > > > I'm not not talking

Re: [Distutils] New PEP : dependency specification

> > > So both the abstract build system PEP and donalds setup.py interface > depend on having a bootstrap dependency list written into a file in > the source tree. your build PEP said stuff like this "Additional data *may* be included, but the ``build_requires`` and ``metadata_version`` keys

Re: [Distutils] Platform tags for OS X binary wheels

If you would like to fix the problem, figure out how to get the real OSX version into pip.pep425tags. On Fri, Nov 6, 2015 at 2:20 PM Robert McGibbon wrote: > For OS X, the pip get_platform function eventually calls into here: >

Re: [Distutils] Platform tags for OS X binary wheels

Sounds good. I'll take a look. -Robert On Fri, Nov 6, 2015 at 11:23 AM, Daniel Holth wrote: > If you would like to fix the problem, figure out how to get the real OSX > version into pip.pep425tags. > > On Fri, Nov 6, 2015 at 2:20 PM Robert McGibbon wrote:

Re: [Distutils] New PEP : dependency specification

On 7 November 2015 at 07:22, Daniel Holth wrote: > LGTM > > To clarify in this spec to specify a couple of requirements for the [foo] > extra would you have to say > > [foo] requests > [foo] sqlalchemy Oh, so this spec describes how to specify a dependency, not how to provide

[Distutils] Platform tags for OS X binary wheels

Hi, I just tried to run `pip install numpy` on my OS X 10.10.3 box, and it proceeds to download and compile the tarball from PyPI from source (very slow). I see, however, that pre-compiled OS X wheel files are available on PyPI for OS X 10.6 and later. Checking the code, it looks like pip is

Re: [Distutils] Platform tags for OS X binary wheels

It should already be sorted. Try python -c "import pprint, pip.pep425tags; pprint.pprint(pip.pep425tags.get_supported())" Do none of the tags for the available numpy wheels appear in that list? On Fri, Nov 6, 2015 at 1:48 PM Robert McGibbon wrote: > Hi, > > I just tried to

Re: [Distutils] Platform tags for OS X binary wheels

I don't think it's the sorting, per se. All of the get_supported() tags are 10.5 or earlier. Here's the output: https://gist.github.com/rmcgibbo/1d0f5d166ca48253b5a9 On Fri, Nov 6, 2015 at 11:00 AM, Daniel Holth wrote: > It should already be sorted. Try python -c "import

Re: [Distutils] The future of invoking pip

On Fri, Nov 6, 2015 at 12:33 PM, Ionel Cristian Mărieș wrote: > ​Why not consider having a "pip" launcher?​ Seems the obvious thing to me > - python has the "py" launcher on windows and it works great! > > Eg: "pip -3" to launch pip using python3, "pip -3.5" to launch pip

Re: [Distutils] Platform tags for OS X binary wheels

I see what you mean. Sounds like a bug to me. On Fri, Nov 6, 2015 at 2:07 PM Robert McGibbon wrote: > I don't think it's the sorting, per se. All of the get_supported() tags > are 10.5 or earlier. Here's the output: > https://gist.github.com/rmcgibbo/1d0f5d166ca48253b5a9 > >

Re: [Distutils] New PEP : dependency specification

On 7 November 2015 at 07:57, Marcus Smith wrote: >> >> So both the abstract build system PEP and donalds setup.py interface >> depend on having a bootstrap dependency list written into a file in >> the source tree. > > > your build PEP said stuff like this "Additional data

Re: [Distutils] Platform tags for OS X binary wheels

For OS X, the pip get_platform function eventually calls into here: https://github.com/python/cpython/blob/master/Lib/_osx_support.py#L429-L439, and I think the comment kind of explains the bug. -Robert On Fri, Nov 6, 2015 at 11:10 AM, Daniel Holth wrote: > I see what you

Re: [Distutils] The future of invoking pip

On Nov 6, 2015 5:39 AM, "Paul Moore" wrote: > > On 6 November 2015 at 12:10, Donald Stufft wrote: > > Doesn’t py.exe just look at some ini files and environment variables to decide what to invoke? I’m not sure why we couldn’t just replicate that behavior.

Re: [Distutils] The future of invoking pip

On 06/11/2015 14:46, Nathaniel Smith wrote: > On Nov 6, 2015 5:39 AM, "Paul Moore" > wrote: >> >> On 6 November 2015 at 12:10, Donald Stufft > wrote: >> > Doesn’t py.exe just look at some ini files and

Re: [Distutils] The future of invoking pip

On Fri, Nov 06, 2015 at 02:04:38PM +1300, Robert Collins wrote: > On 6 November 2015 at 10:08, Donald Stufft wrote: > > * It's more to type, 10 more characters on *nix and 6 more characters on > > Windows which makes it more akward and annoying to use. This is > >

[Distutils] Installing packages using pip

Hello, I want to install the following version of pygame in my windows10.pro:install pygame-1.9.2a0-cp33-none-win_amd64.whl, but the file is in *.whl* format which I dont have any program to open it I checked the information in https://docs.python.org/3/installing/ to understand how to use pip.

Re: [Distutils] The future of invoking pip

On 6 November 2015 at 14:56, Tim Golden wrote: >> One option would be to add a "py -which" mode that just does the >> configuration lookup and then prints the path to the real python >> executable. This would add the cost of one subprocess startup per pip, >> but not 6? > >

Re: [Distutils] Installing packages using pip

On 6 November 2015 at 14:33, Ines Barata wrote: > Hello, > > I want to install the following version of pygame in my > windows10.pro:install pygame-1.9.2a0-cp33-none-win_amd64.whl, but the file > is in .whl format which I dont have any program to open it > I checked

Re: [Distutils] The future of invoking pip

On 11/05/2015 10:08 PM, Donald Stufft wrote: * There is a lot of documentation out there in many projects that tell people to use ``pip install ...``, the long tail on getting people moved to this will be very long. The deprecation period will probably have to be long, but the current

Re: [Distutils] The future of invoking pip

On 6 November 2015 at 12:10, Donald Stufft wrote: > Doesn’t py.exe just look at some ini files and environment variables to > decide what to invoke? I’m not sure why we couldn’t just replicate that > behavior. Is there something that py.exe does that we can’t also do in

Re: [Distutils] New PEP : dependency specification

> > > > No - it specifies the serialisation format for > names/specifiers/extras/markers that is in common use, but doesn't > specify a programming API. It is intended as an interop building > block, I'm not not talking about programming API. this PEP would set the format used in interop

Re: [Distutils] New PEP : dependency specification

> > > The language defined is a compact line based format which is already in > widespread use this is the most critical thing for me, and the reason this approach seems more attractive than the path of PEP426, although I'd certainly like to see Nick's reaction. PEP426 tries to cover how

Re: [Distutils] New PEP : dependency specification

LGTM To clarify in this spec to specify a couple of requirements for the [foo] extra would you have to say [foo] requests [foo] sqlalchemy Compare to requires.txt from setuptools which IIRC is a plain text file like so, with normal requirements not in a section, and extra or conditional

Re: [Distutils] New PEP : dependency specification

On 7 November 2015 at 06:45, Marcus Smith wrote: >> >> The language defined is a compact line based format which is already in >> widespread use > > > this is the most critical thing for me, and the reason this approach seems > more attractive than the path of PEP426, although

Re: [Distutils] The future of invoking pip

On Thu, Nov 5, 2015 at 11:08 PM, Donald Stufft wrote: > Currently pip installs a number of commands like ``pip``, ``pipX`` and > ``pipX.Y`` where the X and X.Y corresponds to the version of Python that > pip > is installed into. Pip installs into whatever Python is currently >

Re: [Distutils] New PEP : dependency specification

Here's an update I just pushed into git that addresses the defects found so far. diff --git a/dependency-specification.rst b/dependency-specification.rst index f8171d8..486636d 100644 --- a/dependency-specification.rst +++ b/dependency-specification.rst @@ -73,7 +73,7 @@ the dependency can be

Re: [Distutils] [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

On 6 November 2015 at 07:39, Ralf Gommers wrote: > On Fri, Nov 6, 2015 at 12:37 AM, Donald Stufft wrote: >> >> If ``pip install —build … —no-clean …`` worked to do incremental builds, >> would that satisfy this use case? (without the —upgrade and

Re: [Distutils] The future of invoking pip

> On Nov 6, 2015, at 1:33 PM, Ionel Cristian Mărieș wrote: > > >> On Thu, Nov 5, 2015 at 11:08 PM, Donald Stufft wrote: >> Currently pip installs a number of commands like ``pip``, ``pipX`` and >> ``pipX.Y`` where the X and X.Y corresponds to the version

Re: [Distutils] [Numpy-discussion] Proposal: stop supporting 'setup.py install'; start requiring 'pip install .' instead

On Mon, Nov 2, 2015 at 5:57 PM, Nathaniel Smith wrote: > On Sun, Nov 1, 2015 at 3:16 PM, Ralf Gommers wrote: >> 2. ``pip install .`` silences build output, which may make sense for some >> usecases, but for numpy it just sits there for minutes with no

Re: [Distutils] The future of invoking pip

On Fri, Nov 6, 2015 at 11:13 PM, Donald Stufft wrote: > Eg: "pip -3" to launch pip using python3, "pip -3.5" to launch pip using > python3.5 - just like the "py" > > > Isn't this basically what the third option is? Just the launcher is also > the entire program. > ​If you

Re: [Distutils] Why github and bitbucket?

On Thu, Nov 5, 2015 at 6:40 PM, Marcus Smith wrote: >> >> >> Basically: Historical reasons. The name “PyPA” was a joke by the >> pip/virtualenv developers and it was only pip and virtualenv so it was on >> Github. > > > here's an anecdote per the pypa.io history page,

Re: [Distutils] The future of invoking pip

On November 6, 2015 at 4:59:39 PM, Ionel Cristian Mărieș (cont...@ionelmc.ro) wrote: > On Fri, Nov 6, 2015 at 11:13 PM, Donald Stufft wrote: > > > Eg: "pip -3" to launch pip using python3, "pip -3.5" to launch pip using > > python3.5 - just like the "py" > > > > > > Isn't this basically what