<div dir="ltr">On 13 July 2013 16:03, Donald Stufft <span dir="ltr"><<a href="mailto:donald@stufft.io" target="_blank">donald@stufft.io</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im"><br>> 1. Install to user-packages by default.<br>
<br>
</div>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 in people's default PATH so they'll easily get into cases where things are installed but they don't know where it was installed too.<br>
</blockquote><div><br></div><div style>I believe Nick wants to make user-packages the default. I know at least some of the pip maintainers (yourself included) have reservations. Personally, I've never used user-packages, so I don't know what issues might arise. But I hope to try it out sometime when I get the chance, just to get some specific information.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> 2. Not depend on setuptools (??? - Nick's "inversion" idea)<br>
<br>
</div>I wanted to do this anyways. It will still "depend" on it, but it will just bundle setuptools itself like its other dependencies. For pip dependencies are an implementation detail not an actual thing it can/should have.<br>
</blockquote><div><br></div><div style>Bundling is not the same as Nick's suggestion. I personally have no problem with bundling, but pip install with a bundled setuptools might not work because the setup subprocess won't see the bundled setuptools when it imports it in setup.py. But either way, it's doable, I just want to know if it's on the critical path...</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
> 3. Possibly change the wrapper command name from pip to pip3 on Unix.<br>
<br>
</div>Not sure on this. Ideally i'd want the commands to be pipX.Y, pipX, and pip all available and not install the less specific ones if they already exist but that might be too hard?<br>
<div class="im"><br>
> 4. Ensure that pip upgrading itself in-place is sufficiently robust and reliable that users don't get "stuck" on the Python-supplied version.<br>
<br>
</div>I've always used pip to upgrade pip. The only time i've had problems is when setuptools messes up (which would be prevented if bundled).<br></blockquote><div><br></div><div style>I've never tried myself, but I'm on Windows and I expect in-place stuff like this to fail. Maybe I'm paranoid :-) Again I need to check.</div>
<div> </div><div style>Thanks for the comments.</div><div style>Paul</div></div><br></div></div>