On 2 November 2011 14:18, Éric Araujo wrote:

Hi Paul,

...

PS D:\Data\PyPI> D:\Data\cpython\PCbuild\python -m packaging.run install nose installing third-party projects from an uninstalled Python is not supported There is a comment in the source to explain that:

 # Python would try to install into the site-packages directory under  # $PREFIX, but when running from an uninstalled code checkout we don't  # want to create directories under the installation root

(Original bug report: #12246)

...

And yet after downloading the nose source... [snip] Ah, I need to reopen the bug.  The patch edited d2.install but forgot to touch the install_commands.

I'm still a bit confused. This is on Windows, and maybe things are different there, but installing seems to just work for me (except for the case where things are to be downloaded). What problem should I look for? 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... Paul.

On 2 November 2011 15:40, Éric Araujo 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 directory). 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 sysconfig.get_path('purelib') 'D:\\Data\\cpython\\Lib\\site-packages' os.path.isdir(sysconfig.get_path('purelib')) True

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 decide. Paul

On 3 November 2011 16:45, Éric Araujo wrote:

I wouldn’t do that: It would trick Python into thinking it’s installed without actually doing all the things that make it installed.

Agreed, it's not good. It's just that I don't know (on Windows) what things *do* make a Python build "installed". I'll see if I can find a definitive statement from somewhere... Paul.

On 4 November 2011 12:11, Mark Hammond wrote:

There really isn't anything that makes it "installed".  A built Python works completely fine just where it is (and indeed, will work just fine if moved somewhere else).  The closest thing to being "installed" on windows is an "InstalledPath" (or something :) registry key for the version, but that is only necessary in a limited number of contexts - when some executable other than the in-place python[w].exe needs to know where things are.

So that would imply that sysconfig.is_python_build is basically meaningless on Windows. So at a minimum, it should always return False on Windows. Actually, it's not part of the public API of sysconfig (it's not in __all__) and it's only used in one place within sysconfig.py, so maybe it should be removed and the check done inline in that one place... Paul.

In article <4EB41FF3.1080304@netwok.org>, Éric Araujo wrote:

Le 04/11/2011 13:11, Mark Hammond a écrit :

...

On 4/11/2011 3:53 AM, Paul Moore wrote:

...

Agreed, it's not good. It's just that I don't know (on Windows) what things *do* make a Python build "installed". I'll see if I can find a definitive statement from somewhere...

There really isn't anything that makes it "installed". A built Python works completely fine just where it is (and indeed, will work just fine if moved somewhere else). The closest thing to being "installed" on windows is an "InstalledPath" (or something :) registry key for the version, but that is only necessary in a limited number of contexts - when some executable other than the in-place python[w].exe needs to know where things are.

Ah, okay. The situation is different on UNIX: Installing Python typically writes the file in read-only mode (one consequence: users have to call setup.py --user, use virtualenv or switch to the superuser to install things), and does not just copy the build dir (so missing data files in the Makefile cause bugs that can only be seen when running the test suite or other code from an installed Python).

One other very important difference: if the build was configured as --enable-shared, the final installed path to the shared library is usually captured in the built python executable. On most Unixy platforms that means you *cannot* reliably run the python executable from the build directory without taking some steps to override the default dynamic library search path, i.e. usually LD_LIBRARY_PATH. In the best case, the interpreter fails to start; in the worst, you get deceptive behavior when the newly built interpreter executable actually runs with a previously installed shared library. This is also true for OS X framework builds, which are a special kind of shared-library builds. -- Ned Deily, nad@acm.org