Where to put a config file for a compiled Python script?
This is similar to Where to put a configuration file in Python?, but I’m asking about scripts compiled/frozen with py2exe or similar on Windows systems. (Namely, this one: What config file format to use for user-friendly strings of arbitrary bytes? https://gist.github.com/1119561) My first thought was to put the config file in the same folder as the .exe, which makes it sort of self-contained. But if I associate files with the .exe, it will be called from their directory, not its own, so I’d need something like How do I get the path of the current executed file in Python? to find the config file. Is this the best way? Or is there some standard config file locations to search in, like https://stackoverflow.com/a/7567946/125507 ?
4 Answers 4
You can use the appdirs module to determine the appropriate folder for user data.
If this is a config file that the user is supposed to edit, then put it somewhere obvious. I tend «compile» python apps in a directory structure like this:
C:/path/to/Application | config.ini | Run Application.bat (runs code/application.exe) | code/ | application.exe | library.zip | . etc. This keeps the «start the app» shortcut and the config file in the same place, easy for the user to find.
If you are using py2exe to package you script, following your links to the one that describes how to determine the path of the executable seems to be the proper way to go. Where you decide to store your config file relative to the exe is up to you. You can either place it in the root of the application directory (next to the exe) or create a config subdir. Its your choice.
On linux machines it can sometimes be common to make use of the etc/ locations for config files. OSX you would either use the users plist preferences location, or an etc. But again in any of these platforms you could also use a relative conf file in the apps directory.
If you were packaging some type of GUI framework, then you could make use of the registry and offer config options through your interface.
I’ve created «compiled» executables in python on widnows that have files types associated with it, and I never had any issues opening my config file which was placed in the same location as the .exe. I used something like this to find it:
conf = open(r"%s\settings.conf" % os.getcwd()) I stored my values separated by a newline character, so the file looked like this:
This stores a username, age, and height, to read the values I would use something like this:
I’d then check the length of the array to make sure the config file wasn’t corrupted or some way, if it was I’d write default values to the file and use those.
sysconfig — Provide access to Python’s configuration information¶
The sysconfig module provides access to Python’s configuration information like the list of installation paths and the configuration variables relevant for the current platform.
Configuration variables¶
A Python distribution contains a Makefile and a pyconfig.h header file that are necessary to build both the Python binary itself and third-party C extensions compiled using distutils .
sysconfig puts all variables found in these files in a dictionary that can be accessed using get_config_vars() or get_config_var() .
Notice that on Windows, it’s a much smaller set.
sysconfig. get_config_vars ( * args ) ¶
With no arguments, return a dictionary of all configuration variables relevant for the current platform.
With arguments, return a list of values that result from looking up each argument in the configuration variable dictionary.
For each argument, if the value is not found, return None .
sysconfig. get_config_var ( name ) ¶
Return the value of a single variable name. Equivalent to get_config_vars().get(name) .
If name is not found, return None .
>>> import sysconfig >>> sysconfig.get_config_var('Py_ENABLE_SHARED') 0 >>> sysconfig.get_config_var('LIBDIR') '/usr/local/lib' >>> sysconfig.get_config_vars('AR', 'CXX') ['ar', 'g++']
Installation paths¶
Python uses an installation scheme that differs depending on the platform and on the installation options. These schemes are stored in sysconfig under unique identifiers based on the value returned by os.name .
Every new component that is installed using distutils or a Distutils-based system will follow the same scheme to copy its file in the right places.
Python currently supports nine schemes:
- posix_prefix: scheme for POSIX platforms like Linux or macOS. This is the default scheme used when Python or a component is installed.
- posix_home: scheme for POSIX platforms used when a home option is used upon installation. This scheme is used when a component is installed through Distutils with a specific home prefix.
- posix_user: scheme for POSIX platforms used when a component is installed through Distutils and the user option is used. This scheme defines paths located under the user home directory.
- posix_venv: scheme for Python virtual environments on POSIX platforms; by default it is the same as posix_prefix .
- nt: scheme for NT platforms like Windows.
- nt_user: scheme for NT platforms, when the user option is used.
- nt_venv: scheme for Python virtual environments on NT platforms; by default it is the same as nt .
- venv: a scheme with values from ether posix_venv or nt_venv depending on the platform Python runs on
- osx_framework_user: scheme for macOS, when the user option is used.
Each scheme is itself composed of a series of paths and each path has a unique identifier. Python currently uses eight paths:
- stdlib: directory containing the standard Python library files that are not platform-specific.
- platstdlib: directory containing the standard Python library files that are platform-specific.
- platlib: directory for site-specific, platform-specific files.
- purelib: directory for site-specific, non-platform-specific files.
- include: directory for non-platform-specific header files for the Python C-API.
- platinclude: directory for platform-specific header files for the Python C-API.
- scripts: directory for script files.
- data: directory for data files.
sysconfig provides some functions to determine these paths.
Return a tuple containing all schemes currently supported in sysconfig .
Return the default scheme name for the current platform.
New in version 3.10: This function was previously named _get_default_scheme() and considered an implementation detail.
Changed in version 3.11: When Python runs from a virtual environment, the venv scheme is returned.
Return a preferred scheme name for an installation layout specified by key.
key must be either «prefix» , «home» , or «user» .
The return value is a scheme name listed in get_scheme_names() . It can be passed to sysconfig functions that take a scheme argument, such as get_paths() .
Changed in version 3.11: When Python runs from a virtual environment and key=»prefix» , the venv scheme is returned.
Return a dict containing preferred scheme names on the current platform. Python implementers and redistributors may add their preferred schemes to the _INSTALL_SCHEMES module-level global value, and modify this function to return those scheme names, to e.g. provide different schemes for system and language package managers to use, so packages installed by either do not mix with those by the other.
End users should not use this function, but get_default_scheme() and get_preferred_scheme() instead.
Return a tuple containing all path names currently supported in sysconfig .
sysconfig. get_path ( name [ , scheme [ , vars [ , expand ] ] ] ) ¶
Return an installation path corresponding to the path name, from the install scheme named scheme.
name has to be a value from the list returned by get_path_names() .
sysconfig stores installation paths corresponding to each path name, for each platform, with variables to be expanded. For instance the stdlib path for the nt scheme is: /Lib .
get_path() will use the variables returned by get_config_vars() to expand the path. All variables have default values for each platform so one may call this function and get the default value.
If scheme is provided, it must be a value from the list returned by get_scheme_names() . Otherwise, the default scheme for the current platform is used.
If vars is provided, it must be a dictionary of variables that will update the dictionary return by get_config_vars() .
If expand is set to False , the path will not be expanded using the variables.
If name is not found, raise a KeyError .
sysconfig. get_paths ( [ scheme [ , vars [ , expand ] ] ] ) ¶
Return a dictionary containing all installation paths corresponding to an installation scheme. See get_path() for more information.
If scheme is not provided, will use the default scheme for the current platform.
If vars is provided, it must be a dictionary of variables that will update the dictionary used to expand the paths.
If expand is set to false, the paths will not be expanded.
If scheme is not an existing scheme, get_paths() will raise a KeyError .
Other functions¶
Return the MAJOR.MINOR Python version number as a string. Similar to ‘%d.%d’ % sys.version_info[:2] .
Return a string that identifies the current platform.
This is used mainly to distinguish platform-specific build directories and platform-specific built distributions. Typically includes the OS name and version and the architecture (as supplied by ‘os.uname()’), although the exact information included depends on the OS; e.g., on Linux, the kernel version isn’t particularly important.
Examples of returned values:
Windows will return one of:
- win-amd64 (64bit Windows on AMD64, aka x86_64, Intel64, and EM64T)
- win32 (all others — specifically, sys.platform is returned)
For other non-POSIX platforms, currently just returns sys.platform .
Return True if the running Python interpreter was built from source and is being run from its built location, and not from a location resulting from e.g. running make install or installing via a binary installer.
sysconfig. parse_config_h ( fp [ , vars ] ) ¶
Parse a config.h -style file.
fp is a file-like object pointing to the config.h -like file.
A dictionary containing name/value pairs is returned. If an optional dictionary is passed in as the second argument, it is used instead of a new dictionary, and updated with the values read in the file.
Return the path of pyconfig.h .
Return the path of Makefile .
Using sysconfig as a script¶
You can use sysconfig as a script with Python’s -m option:
$ python -m sysconfig Platform: "macosx-10.4-i386" Python version: "3.2" Current installation scheme: "posix_prefix" Paths: data = "/usr/local" include = "/Users/tarek/Dev/svn.python.org/py3k/Include" platinclude = "." platlib = "/usr/local/lib/python3.2/site-packages" platstdlib = "/usr/local/lib/python3.2" purelib = "/usr/local/lib/python3.2/site-packages" scripts = "/usr/local/bin" stdlib = "/usr/local/lib/python3.2" Variables: AC_APPLE_UNIVERSAL_BUILD = "0" AIX_GENUINE_CPLUSPLUS = "0" AR = "ar" ARFLAGS = "rc" .
This call will print in the standard output the information returned by get_platform() , get_python_version() , get_path() and get_config_vars() .