On 5 February 2014 01:59, Vinay Sajip <vinay_sajip@yahoo.co.uk> wrote:
On Tue, 4/2/14, Nick Coghlan <ncoghlan@gmail.com> wrote:
Vinay, please let it drop.
You accuse us of FUD, yet have presented no evidence that your approach works flawlessly across multiple versions of Fedora, Debian, openSUSE, RHEL, CentOS, Debian, Ubuntu, Windows, Mac OS X, etc,
I merely asked for a hearing, and made no claims I couldn't substantiate, and with actual code in places. But you seem determined not to give me that hearing, so I'll drop it. It's a shame you have to resort to an argument from authority.
No hearing? You haven't answered *any* of our technical objections, instead dismissing them all as irrelevant. - doesn't work for packages that require installation (which I had forgotten until you reminded me) - doesn't address the distro isolation problem (except by ducking it entirely and saying "don't install it", which isn't a good end user experience, especially on Windows - hence the whole PEP 453 thing so Windows users didn't need to download and run get-pip.py) - doesn't provide a consistent end user experience (what if they *do* install it in some virtual environments and not others?) - doesn't provide any assistance in maintaining a correspondence between pip versions and projects, which at least some freelancers and other contractors see as a valuable capability - should work *in theory* on multiple platforms, but has not been tested broadly on them the way the current approach has Hence, "potentially interesting from a technological perspective, but doesn't solve any of the significant problems currently affecting end users, so not actually all that interesting from a practical perspective" is the natural assessment. It's neat that distil is a standalone script, and hence can be easily run in a venv from outside it, just as venv in Py 3.4 can bootstrap pip without first activating the environment by running "<venv python> -m ensurepip". That's a property of "standalone script" vs "installable package", though, and one that has trade-offs of its own (some of which are noted above) Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia