> Not installing in /usr/local/bin is a feature that makes it easier to maintain
> several python installs without worrying about contamination (for example
> Python
> 3
> and Python 2, or even 2.6 and 2.7).
I thought it might be behaving as designed, but wasn't sure.
Regards,
Vinay Sajip
__
On 15 July 2013 19:30, Ronald Oussoren wrote:
>
> On 13 Jul, 2013, at 7:31, Nick Coghlan wrote:
>>
>> 3. That means there are two main options available to us that I still
>> consider viable alternatives (the installer bundling idea was suggested in
>> one of the off list comments I mentioned):
On 13 Jul, 2013, at 16:39, Vinay Sajip wrote:
>
>
> I smoke-tested the script on vanilla Python 3.3 installations on Windows and
> OS X. On OS X, the pip script was written to the appropriate Frameworks
> folder, but not to /usr/local/bin - I assume it would be simple enough to
> arrange that?
On 13 Jul, 2013, at 15:35, Brett Cannon wrote:
>
>
>
> On Sat, Jul 13, 2013 at 2:29 AM, Ned Deily wrote:
> In article <55b209b3-9576-4cf0-b58c-2a1e692af...@stufft.io>,
> Donald Stufft wrote:
> > On Jul 13, 2013, at 1:31 AM, Nick Coghlan wrote:
> > > I'm currently leaning towards offering
On 13 Jul, 2013, at 7:31, Nick Coghlan wrote:
>
> 3. That means there are two main options available to us that I still
> consider viable alternatives (the installer bundling idea was suggested in
> one of the off list comments I mentioned):
>
> * an explicit bootstrapping script
> * bundli
On Jul 13, 2013, at 6:46 AM, Brett Cannon wrote:
>
>
>
> On Sat, Jul 13, 2013 at 1:31 AM, Nick Coghlan wrote:
> In addition to the long thread based on Richard's latest set of updates, I've
> also received a few off-list comments on the current state of the proposal.
> So, I figured I'd sta
On Jul 13, 2013, at 11:05 AM, Tres Seaver wrote:
> Signed PGP part
> On 07/13/2013 08:25 AM, Nick Coghlan wrote:
> > I think we need to flip the dependencies so that pip as the installer
> > has all the essential code for installation from PyPI and then
> > setuptools and distlib depend on that
On Jul 13, 2013, at 11:00 AM, Paul Moore wrote:
> Of course, saying explicitly "only the python -m pip command line interface
> is stable and supported" may well be enough. But didn't we just say that
> setuptools and distlib depend on the pip API? So either they have special
> privileges (pr
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 07/13/2013 08:25 AM, Nick Coghlan wrote:
> I think we need to flip the dependencies so that pip as the installer
> has all the essential code for installation from PyPI and then
> setuptools and distlib depend on that pip infrastructure. No need to
On 13 July 2013 13:25, Nick Coghlan wrote:
> I think we need to flip the dependencies so that pip as the installer has
> all the essential code for installation from PyPI and then setuptools and
> distlib depend on that pip infrastructure. No need to add anything to the
> standard library prematu
Nick Coghlan gmail.com> writes:
> 1. However we end up solving the bootstrapping problem, I'm *definitely*
> a fan of us updating pyvenv in 3.4 to ensure that pip is available by
> default in new virtual environments created with that tool.
Will that need green-lighting on python-dev? As events
On Sat, Jul 13, 2013 at 9:38 AM, Paul Moore wrote:
> On 13 July 2013 14:31, Brett Cannon wrote:
>
>> +1 on the inversion. I don't know what that will do to pip, it makes
>> sense to have the installer self-contained and the packaging/building
>> libraries be something that you grab using the ins
On Sat, Jul 13, 2013 at 1:31 AM, Nick Coghlan wrote:
> In addition to the long thread based on Richard's latest set of updates,
> I've also received a few off-list comments on the current state of the
> proposal. So, I figured I'd start a new thread summarising my current point
> of view and see
On 13 July 2013 14:31, Brett Cannon wrote:
> +1 on the inversion. I don't know what that will do to pip, it makes sense
> to have the installer self-contained and the packaging/building libraries
> be something that you grab using the installer. Having to grab the
> packaging infrastructure to ge
On Sat, Jul 13, 2013 at 2:29 AM, Ned Deily wrote:
> In article <55b209b3-9576-4cf0-b58c-2a1e692af...@stufft.io>,
> Donald Stufft wrote:
> > On Jul 13, 2013, at 1:31 AM, Nick Coghlan wrote:
> > > I'm currently leaning towards offering both, as we're going to need a
> tool
> > > for bootstrappin
On 13 July 2013 13:25, Nick Coghlan wrote:
> I think we need to flip the dependencies so that pip as the installer has
> all the essential code for installation from PyPI and then setuptools and
> distlib depend on that pip infrastructure. No need to add anything to the
> standard library prematu
On Sat, Jul 13, 2013 at 8:25 AM, Nick Coghlan wrote:
>
> On 13 Jul 2013 19:05, "Paul Moore" wrote:
> >
> > On 13 July 2013 06:31, Nick Coghlan wrote:
> >>
> >> * bundling a *full* copy of pip with the Python installers for Windows
> and Mac OS X, but installing it to site-packages rather than t
On 13 Jul 2013 19:05, "Paul Moore" wrote:
>
> On 13 July 2013 06:31, Nick Coghlan wrote:
>>
>> * bundling a *full* copy of pip with the Python installers for Windows
and Mac OS X, but installing it to site-packages rather than to the
standard library directory. That way pip can be used to upgrade
On 13 July 2013 06:31, Nick Coghlan wrote:
> * bundling a *full* copy of pip with the Python installers for Windows and
> Mac OS X, but installing it to site-packages rather than to the standard
> library directory. That way pip can be used to upgrade itself as normal,
> rather than making it par
On Sat, Jul 13, 2013 at 8:07 AM, Donald Stufft wrote:
> +1 to this as well. Ideally, if we go down this route, installing python
> just comes with pip preinstalled. However that takes place :)
Well, I don't want a "however that takes place" that causes more
packaging problems in the future, so I'
On Jul 13, 2013, at 2:29 AM, Ned Deily wrote:
>> We could simply check it into the site-packages inside the CPython source
>> tree could we not? *Not* providing a bootstrap script and merely checking it
>> into the default site-packages means it's available for everyone. No matter
>> how pyth
On 13 July 2013 16:05, Donald Stufft wrote:
>
> On Jul 13, 2013, at 1:31 AM, Nick Coghlan wrote:
>
> I'm currently leaning towards offering both, as we're going to need a tool
> for bootstrapping source builds, but the simplest way to bootstrap pip for
> Windows and Mac OS X users is to just *bu
In article <55b209b3-9576-4cf0-b58c-2a1e692af...@stufft.io>,
Donald Stufft wrote:
> On Jul 13, 2013, at 1:31 AM, Nick Coghlan wrote:
> > I'm currently leaning towards offering both, as we're going to need a tool
> > for bootstrapping source builds, but the simplest way to bootstrap pip for
> >
On Jul 13, 2013, at 1:57 AM, Noah Kantrowitz wrote:
> I would absolutely advocate to packagers that installing the main python
> package results in a working pip install, regardless of how that is
> accomplished.
+1 to this as well. Ideally, if we go down this route, installing python just
c
On Jul 13, 2013, at 1:31 AM, Nick Coghlan wrote:
> I'm currently leaning towards offering both, as we're going to need a tool
> for bootstrapping source builds, but the simplest way to bootstrap pip for
> Windows and Mac OS X users is to just *bundle a copy with the binary
> installers*. So l
On Jul 12, 2013, at 10:31 PM, Nick Coghlan wrote:
> In addition to the long thread based on Richard's latest set of updates, I've
> also received a few off-list comments on the current state of the proposal.
> So, I figured I'd start a new thread summarising my current point of view and
> see
In addition to the long thread based on Richard's latest set of updates,
I've also received a few off-list comments on the current state of the
proposal. So, I figured I'd start a new thread summarising my current point
of view and see where we want to go from there.
1. However we end up solving t
27 matches
Mail list logo
