On 22 June 2012 13:39, Stephen J. Turnbull <step...@xemacs.org> wrote: > Nick Coghlan writes: > > On Fri, Jun 22, 2012 at 4:25 PM, Stephen J. Turnbull <step...@xemacs.org> > wrote: > > > Paul Moore writes: > > > > > > > End users should not need packaging tools on their machines. > > > > > > I think this desideratum is close to obsolete these days, with webapps > > > in "the cloud" downloading resources (including, but not limited to, > > > code) on an as-needed basis. > > > > There's still a lot more to the software world than what happens on > > the public internet. > > That's taking just one extreme out of context. The other extreme I > mentioned is a whole (virtual) Python environment to go with your app. > > And I don't really see a middle ground, unless you're delivering a > non-standard stdlib anyway, with all the stuff that end users don't > need stripped out of it. They'll get the debugger and the profiler > with Python; should we excise them from the stdlib just because end > users don't need them? How about packaging diagnostic tools, > especially in the early days of the new module? > > I agreed that end users should not need to download the packaging > tools separately or in advance. But that's rather different from > having a *requirement* that the tools not be included, or that > installers should have no dependencies on the toolset outside of a > minimal and opaque runtime module.
I suppose if you're saying that "pip install lxml" should download and install for me Visual Studio, libxml2 sources and any dependencies, and run all the builds, then you're right. But I assume you're not. So why should I need to install Visual Studio just to *use* lxml? On the other hand, I concede that there are some grey areas between the 2 extremes. I don't know enough to do a proper review of the various cases. But I do think that there's a risk that the discussion, because it is necessarily driven by developers, forgets that "end users" really don't have some tools that a developer would consider "trivial" to have. Paul. _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
