If I happen to not have the directory, $PREFIX/python3.3/site-packages, I get an erroneous message telling me that I don't write permissions.

This looks like an invalid bug to me; Python itself creates the site-packages directory, with a README file if I remember correctly.  If the sysadmin removes the directory, it’s their problem, not a Python bug.  Do you agree?

This is probably because Tshepang works in a dev environment.

I think we should have a nice message like "The installation path xxx seems not to exist, aborting installation"

Hm, in my dev environment (checkout of 3.3), site-packages exists.

Strange, you should get a /usr/[local]/lib/python3.3/site-packages when you just run "./configure; make"

It looks like you have a dev environment that has installed some stuff

s/should get/should not get/

Ah, I understand; I have a $srcdir/Lib/site-packages directory, but packaging wants to install into $prefix/site-packages, which does not exist.  +1 to adding a nice message.  Tshepang, would you like to update your patch?

On Fri, 2011-06-03 at 16:18 +0000, Éric Araujo wrote:
> Éric Araujo <merwok@netwok.org> added the comment:
> 
> Ah, I understand; I have a $srcdir/Lib/site-packages directory, but packaging wants to install into $prefix/site-packages, which does not exist.  +1 to adding a nice message.  Tshepang, would you like to update your patch?

Why not just create the directory, instead of print the warning? Is
there any harm?

We do not want to create a directory under $prefix before installation.  This would be a sort of dirty half-installation.  When you have an uninstalled, unconfigured Python, you cannot install modules without giving a prefix option: this sounds good to me.

But this part of the code runs only when you want to install a 3rd party module isn't it? What you are proposing simply adds a delay, for the use will have to then add that directory manually. Or is there something I'm missing here?

s/use/user

I'm not sure I understand your confusion, but perhaps what you are missing is that we don't support installing 3rd party packages inside a source tree, only into an installed Python, and installing Python creates the site-packages directory in $prefix.

Are there cases where my patch would result in site-packages directory installed in an unwanted place?

Yes.  If the directory gets created without Python being installed, then you don't have a working python installation.  Assuming we are talking about site-packages.  I have no idea what purelib is or anything about the packaging internals.

I've changed the patch to represent what I've since learned. It now just displays a message, instead of silently creating the missing path.

Thanks.  What about using sysconfig.is_python_build in your patch?

Find attached.

Great!  I will edit a bit the message and commit this.

New changeset ff58eec3336b by Éric Araujo in branch 'default':
Don’t try to install something when running from uninstalled source (#12246).
http://hg.python.org/cpython/rev/ff58eec3336b

Fixed.  Welcome to Misc/ACKS !

On Fri, 2011-06-10 at 16:46 +0000, Éric Araujo wrote:
> Éric Araujo <merwok@netwok.org> added the comment:
> 
> Fixed.  Welcome to Misc/ACKS !

loveliness :)

Paul Moore reported that a Python built in its checkout on Windows has no problem installing, so I’d like to revisit this.  The patch was also incomplete: The install module was changed, but people could still call “pysetup run install_dist”, and that command was not touched.

To support this on Unix too, we have to either fix sysconfig (#6087) or override some sysconfig paths in packaging.

I will shoot an email at python-dev.  There is no pattern for Lib/site-packages in .hgignore, which makes me think that this issue just never showed up before; I think I need approval before I go ahead.