classification
Title: sysconfg.is_python_build() is buggy
Type: enhancement Stage: resolved
Components: Documentation Versions: Python 3.6, Python 3.5
process
Status: closed Resolution: fixed
Dependencies: Superseder:
Assigned To: docs@python Nosy List: docs@python, matrixise, python-dev, pythonhacker, vinay.sajip, vstinner
Priority: normal Keywords: easy

Created on 2015-03-23 09:13 by pythonhacker, last changed 2016-08-25 14:14 by python-dev. This issue is now closed.

Files
File name Uploaded Description Edit
sysconfig_test.py pythonhacker, 2015-03-23 09:16
Messages (8)
msg238993 - (view) Author: Anand B Pillai (pythonhacker) * Date: 2015-03-23 09:13
On Python 3.5.0a1+ built from source,

>>> import sysconfig
>>> sysconfig.is_python_build()
False
>>> sysconfig.is_python_build(True)
False
>>> sysconfig._PROJECT_BASE
'/opt/bin'
>>> import sys
>>> sys._home
>>>

The problem is, when sys._home is None, this function uses _is_python_source_dir(_PROJECT_BASE) . In this case the _PROJECT_BASE is clearly passed wrongly as '/opt/bin'. That is the INSTALL_PREFIX, not _PROJECT_BASE .

Let us do a small hack and set _PROJECT_BASE to the folder where I build this Python version.

# Of course this can't be reproduced but you get the idea.

>>> sysconfig._PROJECT_BASE='/home/anand/code/cpython/'
>>> sysconfig.is_python_build()
True

The documentation says,

"

sysconfig.is_python_build()

    Return True if the current Python installation was built from source.

"

which is clearly in conflict with what it is doing. 

From a quick look at sysconfig.py it looks like it is calculating _PROJECT_BASE wrongly. 

I can give a patch for this, but first I am more interested in finding out what this function is supposed to do - why have this function if you are not able to get the details of the build environment from the built interpreter ? Clearly it is not doing that here.



The conclusions are part of the attached file in comments.
msg238994 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-03-23 09:24
IMO it's more a documentation issue than a bug.

sysconfig.is_python_build() returns True when Python is run from its source code directory. For example, I compiled Python in ~/prog/python/default.

~/prog/python/default/python returns True.

I installed python to /opt/py35/bin/python: it returns False.
msg238998 - (view) Author: Anand B Pillai (pythonhacker) * Date: 2015-03-23 09:39
Thanks. From current documentation it isn't clear. Agree to make this a doc bug then. 

It should also be made clear this would work only for the executable built in the source directory. As in,

(Running from the source folder using source Python executable).

anand@toshiba-laptop:~/code/cpython$ ./python 
Python 3.5.0a1+ (default:656543a2ad75, Mar  3 2015, 22:56:27) 
[GCC 4.9.2] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import sysconfig
>>> sysconfig.is_python_build()
True
msg239000 - (view) Author: Anand B Pillai (pythonhacker) * Date: 2015-03-23 09:50
On second thoughts, why have such a function if it works correctly only when executed from source Cpython folder using source CPython executable  and not otherwise ?

Cuz if I am calling it like that I already KNOW that I am in such an environment.

Possibly this is an internal function to be used by developers to find out if they are in such an environment.

IMHO Then -> make it private (not callable outside) or drop it altogether.
msg239002 - (view) Author: STINNER Victor (vstinner) * (Python committer) Date: 2015-03-23 09:53
> On second thoughts, why have such a function if it works correctly only when executed from source Cpython folder using source CPython executable  and not otherwise ?

It's useful to know such information. Python behaves a little bit
differently when run from the source code (not installed).

Example of usage of this function:

Lib/test/test_asdl_parser.py:12:if not sysconfig.is_python_build():
Lib/test/test_gdb.py:38:if not sysconfig.is_python_build():
Lib/test/test_pyexpat.py:448:            if sysconfig.is_python_build():
Lib/test/test_subprocess.py:415:
@unittest.skipIf(sysconfig.is_python_build(),
msg239003 - (view) Author: Anand B Pillai (pythonhacker) * Date: 2015-03-23 10:16
> Lib/test/test_asdl_parser.py:12:if not sysconfig.is_python_build():

As I guessed - it is used internally by unit tests and possibly has no other significan audience.

It is best to document this clearly.
msg273649 - (view) Author: Vinay Sajip (vinay.sajip) * (Python committer) Date: 2016-08-25 13:12
It's not *only* used in test - it's also used in third party libraries. For example, it's used in distlib (which is vendored by pip) to determine whether it's being run from a source build.
msg273651 - (view) Author: Roundup Robot (python-dev) (Python triager) Date: 2016-08-25 14:14
New changeset bf51f1f3569a by Vinay Sajip in branch '3.5':
Issue #23746: Clarified is_python_build() documentation.
https://hg.python.org/cpython/rev/bf51f1f3569a

New changeset a0a7c5b1af97 by Vinay Sajip in branch 'default':
Closes #23746: merged update from 3.5.
https://hg.python.org/cpython/rev/a0a7c5b1af97
History
Date User Action Args
2016-08-25 14:14:27python-devsetstatus: open -> closed

nosy: + python-dev
messages: + msg273651

resolution: fixed
stage: needs patch -> resolved
2016-08-25 13:12:50vinay.sajipsetnosy: + vinay.sajip
messages: + msg273649
2016-08-08 06:06:07matrixisesetnosy: + matrixise
2016-07-31 11:26:39berker.peksagsetkeywords: + easy
stage: needs patch
type: enhancement
components: - Library (Lib)
versions: + Python 3.6, - Python 3.4
2015-03-29 13:12:28pythonhackersetassignee: docs@python
components: + Documentation
2015-03-29 13:12:16pythonhackersetnosy: + docs@python
2015-03-23 10:16:23pythonhackersetmessages: + msg239003
2015-03-23 09:53:27vstinnersetmessages: + msg239002
2015-03-23 09:50:07pythonhackersetmessages: + msg239000
2015-03-23 09:39:23pythonhackersetmessages: + msg238998
2015-03-23 09:24:04vstinnersetnosy: + vstinner
messages: + msg238994
2015-03-23 09:16:15pythonhackersetfiles: + sysconfig_test.py
2015-03-23 09:13:02pythonhackercreate