On 17 July 2013 00:56, Donald Stufft don...@stufft.io wrote:
On Jul 16, 2013, at 1:36 PM, Matthias Klose d...@ubuntu.com wrote:
5. Support cross-compilation of extensions by default.
TBH I don't know how much of this has anything to do with pip? As far as
compiling goes all pip does is call
On 17 July 2013 00:56, Donald Stufft don...@stufft.io wrote:
On Jul 16, 2013, at 1:36 PM, Matthias Klose d...@ubuntu.com wrote:
5. Support cross-compilation of extensions by default.
TBH I don't know how much of this has anything to do with pip? As far as
compiling goes all pip does is
On 17 July 2013 20:00, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 17 July 2013 00:56, Donald Stufft don...@stufft.io wrote:
On Jul 16, 2013, at 1:36 PM, Matthias Klose d...@ubuntu.com wrote:
5. Support cross-compilation of extensions by default.
TBH I don't know how much of this
On 16 July 2013 00:12, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
On 15 July 2013 23:39, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Mon, Jul 15, 2013 at 3:28 PM, Donald Stufft don...@stufft.io wrote:
There is something like 200 total bdist_msi on PyPI and 5k
On Jul 15, 2013, at 6:39 PM, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Mon, Jul 15, 2013 at 3:28 PM, Donald Stufft don...@stufft.io wrote:
There is something like 200 total bdist_msi on PyPI and 5k bdist_wininst.
To put numbers into perspective, there are ~180k total
Am 13.07.2013 16:54, schrieb Paul Moore:
1. Install to user-packages by default.
2. Not depend on setuptools (??? - Nick's inversion idea)
3. Possibly change the wrapper command name from pip to pip3 on Unix.
4. Ensure that pip upgrading itself in-place is sufficiently robust and
reliable
On Jul 16, 2013, at 1:36 PM, Matthias Klose d...@ubuntu.com wrote:
5. Support cross-compilation of extensions by default.
TBH I don't know how much of this has anything to do with pip? As far as
compiling goes all pip does is call setup.py install so people are compiling
with either
On 13 July 2013 20:59, Paul Moore p.f.mo...@gmail.com wrote:
It would be nice to get feedback from normal users on this. I suspect that
the scientific community would make a good cross-section (AIUI there's quite
a lot of Windows use, and for many people in the community Python is very
much a
On 15 July 2013 15:16, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
I don't know if I really count as a normal user but I can describe how
Python is installed on the Windows machines in my faculty for
scientific use.
Thanks, that's interesting.
Do people typically write command-line
On 15 July 2013 15:21, Paul Moore p.f.mo...@gmail.com wrote:
On 15 July 2013 15:16, Oscar Benjamin oscar.j.benja...@gmail.com wrote:
I don't know if I really count as a normal user but I can describe how
Python is installed on the Windows machines in my faculty for
scientific use.
Thanks,
On Sat, Jul 13, 2013 at 12:59 PM, Paul Moore p.f.mo...@gmail.com wrote:
2. This sounds like something that needs fixed on Windows. Even if you say
``-m`` for pip then things are still broken by default for any other package
on PyPI that installs a script. So this feels like something wrong with
On 15 July 2013 17:47, Chris Barker - NOAA Federal chris.bar...@noaa.govwrote:
I don't _think_ this is just Windows Bashing: MS has done very very
little to improve the whole command line experience on Windows over
the years.
It's not MS-bashing. I agree with you, and I'm one of the least
On 15 July 2013 18:11, Paul Moore p.f.mo...@gmail.com wrote:
The real problem is not technical, actually - it's knowing what Windows
users will actually be comfortable with. Unix users tend to assume Windows
users are very uncomfortable on the command line (no offence meant to anyone
by that)
On Mon, Jul 15, 2013 at 10:11 AM, Paul Moore p.f.mo...@gmail.com wrote:
of Steve Dower, I guess :-)) Powershell is a *great* step up from cmd,
could we use a powershell script to launch python scripts? Maybe it
wouldn't be any easier to update than an exe, but it might be more
accessible.
Of
On 15 July 2013 23:09, Chris Barker - NOAA Federal chris.bar...@noaa.govwrote:
For simple cases yes, but we have
bdist_wininst and bdist_msi for those, and they are clearly not enough.
but they are really widely used -- maybe when binary wheels become
ubiqitous, I'll stop using them, but
On Jul 15, 2013, at 6:22 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 15 July 2013 23:09, Chris Barker - NOAA Federal chris.bar...@noaa.gov
wrote:
For simple cases yes, but we have
bdist_wininst and bdist_msi for those, and they are clearly not enough.
but they are really widely used
On Jul 15, 2013, at 6:24 PM, Donald Stufft don...@stufft.io wrote:
On Jul 15, 2013, at 6:22 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 15 July 2013 23:09, Chris Barker - NOAA Federal chris.bar...@noaa.gov
wrote:
For simple cases yes, but we have
bdist_wininst and bdist_msi for
On Mon, Jul 15, 2013 at 3:28 PM, Donald Stufft don...@stufft.io wrote:
There is something like 200 total bdist_msi on PyPI and 5k bdist_wininst.
To put numbers into perspective, there are ~180k total files uploaded to
PyPI.
I don't hink this means that the installers aren't widely used, I
On 15 July 2013 23:39, Chris Barker - NOAA Federal
chris.bar...@noaa.gov wrote:
On Mon, Jul 15, 2013 at 3:28 PM, Donald Stufft don...@stufft.io wrote:
There is something like 200 total bdist_msi on PyPI and 5k bdist_wininst.
To put numbers into perspective, there are ~180k total files uploaded
On Jul 13, 2013, at 10:58 PM, Nick Coghlan wrote:
On 14 July 2013 12:46, Donald Stufft don...@stufft.io wrote:
I'm sure I've seen people say other things that have made me think are you
expecting the pip maintainers to make that change? in the various threads,
so I doubt this list is
On 14 July 2013 16:19, Noah Kantrowitz n...@coderanger.net wrote:
On Jul 13, 2013, at 10:58 PM, Nick Coghlan wrote:
On 14 July 2013 12:46, Donald Stufft don...@stufft.io wrote:
Either the existing APIs are moved to a different name, or they get
declared stable and pip switches to internally
On 14 July 2013 16:34, Nick Coghlan ncogh...@gmail.com wrote:
On 14 July 2013 16:19, Noah Kantrowitz n...@coderanger.net wrote:
On Jul 13, 2013, at 10:58 PM, Nick Coghlan wrote:
On 14 July 2013 12:46, Donald Stufft don...@stufft.io wrote:
Either the existing APIs are moved to a different
On Jul 14, 2013, at 1:58 AM, Nick Coghlan ncogh...@gmail.com wrote:
Either the existing APIs are moved to a different name, or they get declared
stable and pip switches to internally forked APIs any time a backwards
incompatible change is needed for refactoring purposes (see
On 14 July 2013 16:43, Donald Stufft don...@stufft.io wrote:
I just want to make sure that the boundaries between the governance of
Python and pip are clearly defined and the expectations on both sides are
laid out and agreed upon before it happens. And I think this raises a good
point about
On Jul 14, 2013, at 3:01 AM, Nick Coghlan ncogh...@gmail.com wrote:
On 14 July 2013 16:43, Donald Stufft don...@stufft.io wrote:
I just want to make sure that the boundaries between the governance of Python
and pip are clearly defined and the expectations on both sides are laid out
and
On 14 July 2013 17:13, Donald Stufft don...@stufft.io wrote:
I think it would be reasonable for the pip maintainers to be asked to
declare a public API (even if that's None) using the naming scheme or an
import warning and declare a backwards compatibility policy for pip itself
so that people
I do think pip is pretty conservative about backwards compat other than the
security related changes I've been doing.
I think we can find the middle ground that lets things work smoothly here :). I
was just making sure that we wernt going to have to keep things around for
really long times
On 14 July 2013 17:50, Donald Stufft don...@stufft.io wrote:
I do think pip is pretty conservative about backwards compat other than
the security related changes I've been doing.
I think we can find the middle ground that lets things work smoothly here
:). I was just making sure that we
On Jul 14, 2013, at 12:35 AM, Nick Coghlan wrote:
On 14 July 2013 17:13, Donald Stufft don...@stufft.io wrote:
I think it would be reasonable for the pip maintainers to be asked to declare
a public API (even if that's None) using the naming scheme or an import
warning and declare a
On 14 Jul 2013 18:24, Noah Kantrowitz n...@coderanger.net wrote:
On Jul 14, 2013, at 12:35 AM, Nick Coghlan wrote:
On 14 July 2013 17:13, Donald Stufft don...@stufft.io wrote:
I think it would be reasonable for the pip maintainers to be asked to
declare a public API (even if that's None)
On Sun, Jul 14, 2013 at 4:23 AM, Noah Kantrowitz n...@coderanger.netwrote:
On Jul 14, 2013, at 12:35 AM, Nick Coghlan wrote:
On 14 July 2013 17:13, Donald Stufft don...@stufft.io wrote:
I think it would be reasonable for the pip maintainers to be asked to
declare a public API (even if
This issue has been skirted round for some time now, and I think it needs
explicit discussion, as I am not at all sure everyone has the same
expectations.
We're talking about Python 3.4 installations having pip as the default
package manager - whether by bundling, having a bootstrap process or
Also (see my reply to Nick's inversion proposal) we can add:
5. Provide a stable documented programming interface.
Paul
On 13 July 2013 15:54, Paul Moore p.f.mo...@gmail.com wrote:
This issue has been skirted round for some time now, and I think it needs
explicit discussion, as I am not at
On Jul 13, 2013, at 10:54 AM, Paul Moore p.f.mo...@gmail.com wrote:
This issue has been skirted round for some time now, and I think it needs
explicit discussion, as I am not at all sure everyone has the same
expectations.
We're talking about Python 3.4 installations having pip as the
On Jul 13, 2013, at 11:01 AM, Paul Moore p.f.mo...@gmail.com wrote:
5. Provide a stable documented programming interface.
As I said in the other thread I don't think this is required any more than it
does normally.
I do think we need to have testing infrastructure in pip that tests against
On 13 July 2013 16:03, Donald Stufft don...@stufft.io wrote:
1. Install to user-packages by default.
Do people really want this? I hadn't seen it (other than if pip was
installed to user by default). I think it's a bad idea to switch this on
people. I doubt the user-packages is going to be
On Sat, Jul 13, 2013 at 11:15 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 13 July 2013 16:03, Donald Stufft don...@stufft.io wrote:
1. Install to user-packages by default.
Do people really want this? I hadn't seen it (other than if pip was
installed to user by default). I think it's a
1. Install to user-packages by default.
there was a thread a few weeks back on this. everyone seemed to agree at
the end that just better error messages were enough. changing the default
install location is a huge leap.
http://mail.python.org/pipermail/distutils-sig/2013-May/020673.html
2) replacing pkg_resources with distlib (vinay posted a PR for this)
3) if not #1, pip installing setuptools on-demand when building is needed
(this was the old plan I think for PEP439 until the recent changes, and
get's us closer to the MEBs model)
to be clearer for everyone, #3 depends
On Jul 13, 2013, at 12:59 PM, Brett Cannon br...@python.org wrote:
Could we just start to move away from an executable script and start
promoting rather aggressively -m instead? It truly solves this problem and
since the results are tied to the Python executable used (i.e. where
something
On Jul 13, 2013, at 9:59 AM, Brett Cannon wrote:
On Sat, Jul 13, 2013 at 11:15 AM, Paul Moore p.f.mo...@gmail.com wrote:
On 13 July 2013 16:03, Donald Stufft don...@stufft.io wrote:
1. Install to user-packages by default.
Do people really want this? I hadn't seen it (other than if
On Jul 13, 2013, at 12:59 PM, Brett Cannon br...@python.org wrote:
Could we just start to move away from an executable script and start
promoting rather aggressively -m instead? It truly solves this problem and
since the results are tied to the Python executable used (i.e. where
something
On 13 July 2013 18:30, Donald Stufft don...@stufft.io wrote:
On Jul 13, 2013, at 12:59 PM, Brett Cannon br...@python.org wrote:
Could we just start to move away from an executable script and start
promoting rather aggressively -m instead? It truly solves this problem and
since the results
On 13 July 2013 18:51, Donald Stufft don...@stufft.io wrote:
On Jul 13, 2013, at 12:59 PM, Brett Cannon br...@python.org wrote:
Could we just start to move away from an executable script and start
promoting rather aggressively -m instead? It truly solves this problem and
since the results
On Jul 13, 2013, at 1:55 PM, Paul Moore p.f.mo...@gmail.com wrote:
1. It's not *actually* the case that the command is always pip. Maybe it's
pip3 if your system makes the default Python be python 2, but you want to
use python 3. Maybe you're creating a virtualenv and you haven't activated
On 13 July 2013 19:24, Donald Stufft don...@stufft.io wrote:
2. This sounds like something that needs fixed on Windows. Even if you say
``-m`` for pip then things are still broken by default for any other
package on PyPI that installs a script. So this feels like something wrong
with Python
On Jul 13, 2013, at 3:59 PM, Paul Moore p.f.mo...@gmail.com wrote:
On 13 July 2013 19:24, Donald Stufft don...@stufft.io wrote:
2. This sounds like something that needs fixed on Windows. Even if you say
``-m`` for pip then things are still broken by default for any other package
on PyPI
On 13 July 2013 21:14, Donald Stufft don...@stufft.io wrote:
I don't know any windows users off hand except for you ;) (And you already
said you use ``pip`` and not ``python -m pip`` which already works with pip
:)
You caught me :-) My problem is that I'm pretty sure I'm seriously atypical
On Jul 13, 2013, at 6:44 PM, Steve Dower steve.do...@microsoft.com wrote:
Because of the issues around compilation on Windows, we believe that most
users avoid pip in favor of precompiled installers. The model of download an
executable that matches my Python version and run it is more
Because of the issues around compilation on Windows, we believe that most users
avoid pip in favor of precompiled installers. The model of download an
executable that matches my Python version and run it is more familiar than a
command line tool, and unlikely to go away anytime soon.
Those who
Paul Moore p.f.moore at gmail.com writes:
4. Ensure that pip upgrading itself in-place is sufficiently robust and
reliable that users don't get stuck on the Python-supplied version.
Perhaps one could add to your list, the ability to downgrade to the previous
version should there be a problem
On 14 July 2013 00:54, Paul Moore p.f.mo...@gmail.com wrote:
This issue has been skirted round for some time now, and I think it needs
explicit discussion, as I am not at all sure everyone has the same
expectations.
We're talking about Python 3.4 installations having pip as the default
On Jul 13, 2013, at 10:20 PM, Nick Coghlan ncogh...@gmail.com wrote:
On 14 July 2013 00:54, Paul Moore p.f.mo...@gmail.com wrote:
This issue has been skirted round for some time now, and I think it needs
explicit discussion, as I am not at all sure everyone has the same
expectations.
It is easy to forget that pip only needs the package database part
of setuptools (pkg_resources.py) to install things. With the small
catch that the rest of setuptools is required to install anything
besides wheels.
MEBS is just about implementing build requirements properly and giving
pip a
On 14 July 2013 12:46, Donald Stufft don...@stufft.io wrote:
I'm sure I've seen people say other things that have made me think are
you expecting the pip maintainers to make that change? in the various
threads, so I doubt this list is definitive.
The other big one is the one you noted about
55 matches
Mail list logo
