[Python-Dev] Status of packaging in 3.3

Paul Moore p.f.moore at gmail.com
Fri Jun 22 15:24:19 CEST 2012


On 22 June 2012 13:39, Stephen J. Turnbull <stephen at xemacs.org> wrote:
> Nick Coghlan writes:
>  > On Fri, Jun 22, 2012 at 4:25 PM, Stephen J. Turnbull <stephen at 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.


More information about the Python-Dev mailing list