This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author fdrake
Recipients fdrake, tarek
Date 2008-04-04.05:42:36
SpamBayes Score 0.020178203
Marked as misclassified No
Message-id <1207287758.75.0.987615225083.issue2385@psf.upfronthosting.co.za>
In-reply-to
Content
I don't think these are the right thing to do.

1. Your run_setup() changes add a os.chdir(), but then uses the path to
   the script as passed in; this assumes that the provided path is
   absolute, which is not a good assumption.  That is not currently
   required.  The effect is that a path that works currently may not
   work after the change.  A relative path will not be usable to locate
   support files in this case, since it no longer refers to the
   directory is used to.

   Also, the way you restore the current directory doesn't work;
   os.curdir isn't what you think it is.  This isn't covered in the
   test, either.

2. Apparently there are setup.py scripts that test __name__ (this
   surprised me, but Google Code Search says there are many:
   http://www.google.com/codesearch?q=file%3Asetup.py+%22__main__%22).
   This change would affect those that are currently seeing
   "__builtin__" (picked up from the built-in namespace).

Arguably, it's reasonable to expect run_setup() to restore the current
directory if a setup.py script does change it, but it's not clear that
the change in behavior wouldn't cause problems for existing scripts.

I've adjusted the patch so that the __file__ is supported, but the other
behaviors are omitted.  This has been commited in revision 62142 on the
trunk.
History
Date User Action Args
2008-04-04 05:42:39fdrakesetspambayes_score: 0.0201782 -> 0.020178203
recipients: + fdrake, tarek
2008-04-04 05:42:38fdrakesetspambayes_score: 0.0201782 -> 0.0201782
messageid: <1207287758.75.0.987615225083.issue2385@psf.upfronthosting.co.za>
2008-04-04 05:42:37fdrakelinkissue2385 messages
2008-04-04 05:42:36fdrakecreate