[Distutils] Odd limitation in packaging/distutils2
p.f.moore at gmail.com
Wed Nov 2 20:27:27 CET 2011
On 2 November 2011 15:40, Éric Araujo <merwok at netwok.org> wrote:
> Can you define what you mean with “just work”? Does it install things
> into $checkout/Lib/site-packages?
Seems to. Certainly does for my own packages.
>> The reason I care is that installing packages into a dev build is
>> really useful for testing packaging changes. I'm not actually sure how
>> to turn a dev build into an installed build on Windows...
> http://docs.python.org/devguide/#quick-start : “On Windows, load the
> project file PCbuild\pcbuild.sln in Visual Studio, select Debug, and
> Build -> Build Solution;”
Sorry, I wasn't clear. That I know. But that produces what I assume
counts as a "non-installed" build (with python.exe in the PCBuild
Looking at is_python_build, it's just checking for the existence of
Modules\Setup.*, so I suppose I could just rename or delete those
files. It all seems a bit arbitrary, though.
On a non-installed Python build (i.e., python built in a checkout) on
Windows, purelib and site-packages look fine:
PS D:\Data> D:\Data\cpython\PCbuild\python.exe
Python 3.3.0a0 (default, Oct 28 2011, 19:56:45) [MSC v.1500 32 bit
(Intel)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig, os
It looks like this might be a Unix-only issue - if so, can I suggest
that the restriction be removed on Windows, as it *is* useful to be
able to install packages in a non-installed Python build.
I'd argue that on Unix, get_path('purelib') should find the right
site-packages even for an uninstalled build. But I've no idea if
that's too hard, or is somehow otherwise an issue. And I don't need
the functionality myself, so I'll leave that one for the Unix users to
More information about the Distutils-SIG