[Python-Dev] Status of packaging in 3.3 (original) (raw)

Stephen J. Turnbull stephen at xemacs.org
Sat Jun 23 10:02:18 CEST 2012

Paul Moore writes:

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.

Indeed, if only a source package is available, it should. That's precisely what happens for source builds that depend on a non-system compiler on say Gentoo or MacPorts. What I'm saying is that the packaging system should always be prepared to offer that service (perhaps via plugins to OS distros' PMSes). Whether a particular package does, or not, presumably is up to the package's maintainer.

Even if a binary package is available, it may only be partial. Indeed, by some definitions it alway will be (it will depend on an OS being installed!) Such a package should also offer the ability to fix up an incomplete system, by building from source if needed.

Why can I say "should" here? Because if the packaging standard is decent and appropriate tools provided, there will be a source package because it's the easiest way to create a distribution! Such tools will surely be able to search the system for a preinstalled dependency, or a binary package cache for an installable package. A "complete" binary package would just provide the package cache on its distribution medium.

So why should I need to install Visual Studio just to use lxml?

Because the packaging standard cannot mandate "high quality" packages from any given user's perspective, it can only provide the necessary features to implement them. If the lxml maintainer chooses to depend on a pre-installed libxml2, AFAICS you're SOL -- you need to go elsewhere for the library. VS + libxml2 source is just the most reliable way to go elsewhere in some sense (prebuilt binaries have a habit of showing up late or built with incompatible compiler options or the like).

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.

I don't understand the problem. As long as binary packages have a default spec to depend on nothing but a browser to download the MSI, all you need is a buildbot that has a minimal Windows installation, and it won't be forgotten. The developers may forget to check, but the bot will remember! I certainly agree that the default spec should be that if you can get your hands on binary installer, that's all you need -- it will do all the work needed. Heck, it's not clear to me what else the default spec might be for a binary package.

OTOH, if the developers make a conscious decision to depend on a given library, and/or a compiler, being pre-installed on the target system, what can Python or the packaging standard do about that?

More information about the Python-Dev mailing list