[issue10263] "python -m site" does not print path details

Éric Araujo added the comment: Sounds good to me. -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://ma

[issue10263] "python -m site" does not print path details

Nick Coghlan added the comment: Ah, yes, I see what you mean - because runpy ignores the sys.modules cache (by design), it won't see the precached module instance placed there by the bootstrap code. We actually *could* make this work on our end: if we find an existing module in sys.modules,

[issue10263] "python -m site" does not print path details

Ned Deily added the comment: The issue here is not unique to OS X. I see the same behavior on Linux with a built-from-source Python 3.2a3 and Distribute 0.6.14. (As I noted earlier, Debian and presumably various other distributors package a patched version of setuptools / Distribute which doe

[issue10263] "python -m site" does not print path details

Nick Coghlan added the comment: Yeah, because the internal import system isn't fully exposed, runpy and a couple of other tools in the standard library rely on the emulation in pkgutil instead. I know there are some differences between the emulation and the builtin mechanism on Windows in ter

[issue10263] "python -m site" does not print path details

Ned Deily added the comment: Nick is the authority on -m so perhaps he can confirm this but I believe the execution of -m is carried out by the runpy standard library module and the runpy module essentially goes through the process of finding a module from scratch by searching through the mod

[issue10263] "python -m site" does not print path details

Changes by Doug Hellmann : -- nosy: +tarek ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.python.o

[issue10263] "python -m site" does not print path details

Doug Hellmann added the comment: Adding a print to the site.py in Distribute's egg shows it is being run when I use 'python -m site'. However, when I run 'python -c "import site; print site.__file__"' I get the version from the stdlib, as expected. I guess the module finding mechanism for -m

[issue10263] "python -m site" does not print path details

Ned Deily added the comment: For me, python2.6 exhibits the same behavior as python2.7, using either Distribute 0.6.14 or 0.6.10 for both (this is on OS X with a stock framework build but that should not be significant). Perhaps you have a file permissions problem with your 2.6 site-packages

[issue10263] "python -m site" does not print path details

Doug Hellmann added the comment: That's strange. I have Distribute 0.6.10, including an easy-install.pth file, installed under 2.6 and it doesn't exhibit the problem. Is there some interaction between a change in Python 2.7 and Distribute? -- ___

[issue10263] "python -m site" does not print path details

Ned Deily added the comment: Unfortunately, the problem here is caused by having setuptools or Distribute installed. As released, both setuptools and Distribute install an easy-install.pth into site-packages to insert its "egg" into sys.path. If you look inside the egg, you'll see it has its

[issue10263] "python -m site" does not print path details

Nick Coghlan added the comment: No, there won't be another binary release until 2.7.1 comes out. The SVN revision number ratchets up pretty fast, since it is counting checkins on *all* branches, even experimental ones. -- ___ Python tracker

[issue10263] "python -m site" does not print path details

Doug Hellmann added the comment: Ah, I assumed that since the revision number was older there might be a newer build available now. -- ___ Python tracker ___ __

[issue10263] "python -m site" does not print path details

Nick Coghlan added the comment: r82508 is the correct release binary (created after the error I mentioned above was fixed). I've CC'ed Ronald to see if he can shed any light - it may be a platform specific issue with the way sys.path is calculated. -- ___

[issue10263] "python -m site" does not print path details

Doug Hellmann added the comment: Actually I'm trying to update the PyMOTW article about site, and I discovered that the output from the old examples that showed using --user-base and --user-site were no longer producing any output. It looks like the build of 2.7 I downloaded is fairly old, s

[issue10263] "python -m site" does not print path details

Changes by Nick Coghlan : -- nosy: +ronaldoussoren ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http://mail.

[issue10263] "python -m site" does not print path details

Nick Coghlan added the comment: Note also that site.py runs twice when used with -m: once implicitly during interpreter startup, and a second time as the main module. Due to the way the interpreter starts up and figures out sys.path, it is possible for the implicit import to pick up the corre

[issue10263] "python -m site" does not print path details

Doug Hellmann added the comment: I downloaded an OS X installer from python.org, but I don't remember the date I did that. Here's the output when I start the interpreter: $ which python /Library/Frameworks/Python.framework/Versions/2.7/bin/python $ python Python 2.7 (r27:82508, Jul 3 2010, 2

[issue10263] "python -m site" does not print path details

Nick Coghlan added the comment: Since it works for me (I tried both r84120, my old 2.7 build from August or so, and r86033, which is the 2.7 head), we'll need more information. The starting blurb from the interactive prompt would be a good place to start. (-m was slightly broken from April-Ju

[issue10263] "python -m site" does not print path details

Changes by Antoine Pitrou : -- nosy: +eric.araujo, ncoghlan ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: htt

[issue10263] "python -m site" does not print path details

New submission from Doug Hellmann : Running "python -m site" is supposed to print a report about the current import path and its components (like USER_BASE and USER_SITE). This works under 2.6 and 3.1, but not 2.7. No output is produced under 2.7 at all. When I add a print statement to the