shuup.apps package

Submodules

shuup.apps.provides module

This module contains the API to deal with the Provides system.

The Provides system is Shuup’s mechanism for discovering and loading components, both first-party and third-party.

See also

See /provides for further information about the Provides system.

shuup.apps.provides.clear_provides_cache()

shuup.apps.provides.get_provide_specs_and_objects(category)

Get a mapping of provide specs (“x.y.z:Q”) to their loaded objects (<class Q>).

Parameters:category (str) – Category to load objects for. Returns:Dict of spec -> object. Return type:dict[str, object]

shuup.apps.provides.get_provide_objects(category)

Get an iterable of provide objects for the given category.

Parameters:category (str) – Category to load objects for. Returns:Iterable of objects. Return type:Iterable[object]

shuup.apps.provides.get_identifier_to_spec_map(category)

shuup.apps.provides.get_identifier_to_object_map(category)

shuup.apps.provides.override_provides(category, spec_list)

Context manager to override provides for a given category.

Useful for testing.

Parameters:

• category (str) – Category name.
• spec_list (list[str]) – List of specs.

shuup.apps.provides.load_module(setting_name, provide_category)

Load a module from a module setting.

The value of the setting must be a module identifier for the given provide category.

Parameters:

• setting_name (str) – The setting name for the identifier.
• provide_category (str) – The provide category for the identifier lookup (e.g. tax_module).

Returns:

An object.

Return type:

Any

shuup.apps.provides.load_modules(setting_name, provide_category)

Load a list of modules from a module setting.

The value of the setting must be a list of module identifiers for the given provide category.

The modules are returned in the same order they are declared in the settings.

Parameters:

• setting_name (str) – The setting name for the identifier list.
• provide_category (str) – The provide category for the identifier lookup (e.g. tax_module).

Returns:

A list of objects.

Return type:

list[Any]

shuup.apps.provides.load_module_instances(setting_name, provide_category)

Load a list of initialized modules from a module setting.

Basically does the same as load_modules, but also initializes the loaded modules by calling them.

shuup.apps.settings module

shuup.apps.settings.collect_settings_from_app(app_config)

shuup.apps.settings.collect_settings(app_name, settings_module)

shuup.apps.settings.get_known_settings()

Get all settings known to Shuup.

Return type:Iterable[Setting]

class shuup.apps.settings.Setting(name, default, app_name, module)

Bases: object

shuup.apps.settings.validate_templates_configuration()

Validate the TEMPLATES configuration in the Django settings.

Shuup’s admin and default frontend require some Django-Jinja configuration, so let’s make sure clients configure their projects correctly.

Raises:Raises ImproperlyConfigured if the configuration does not seem valid. Returns: Return type:

shuup.apps.settings.reload_apps()

Module contents

Shuup Application API

Every Shuup Application should define an app config class derived from shuup.apps.AppConfig.

Settings

To define settings for a Shuup Application, add a settings.py file to your app and define each setting as a module level variable with uppercase name. The values of these setting variables will be used as the default values for the settings. To document a setting, add a special comment block using ‘#: ‘ prefixed lines just before the setting assignment line.

Default values can then be changed normally by defining the changed value in your Django settings module. To read a value of a setting use the django.conf.settings interface.

For example, if a fancy app lives in a Python package named fancyapp, its settings will be in module fancyapp.settings and if it contains something like this

#: Number of donuts to use
#:
#: Must be less than 42.
FANCYAPP_NUMBER_OF_DONUTS = 3

then this would define a setting FANCYAPP_NUMBER_OF_DONUTS with a default value of 3.

See also source code of shuup.core.settings.

Naming Settings

Applications in Shuup Base distribution should use the following rules for naming their settings.

1. Each setting should be prefixed with the string SHUUP_
2. Boolean toggle settings should have a verb in imperative mood as part of the name, e.g. SHUUP_ALLOW_ANONYMOUS_ORDERS, SHUUP_ENABLE_ATTRIBUTES or SHUUP_ENABLE_MULTIPLE_SHOPS.
3. Setting that is used to locate a replaceable module should have suffix _SPEC or _SPECS (if the setting is a list or mapping of those), e.g. SHUUP_PRICING_MODULE_SPEC.
4. Setting names do NOT have to be prefixed with the application name. For example, SHUUP_BASKET_VIEW_SPEC which is not prefixed with SHUUP_FRONT even though it is from shuup.front application.
5. Setting names should be unique; if two applications define a setting with a same name, they cannot be enabled in the same installation.

Warning

When you have a settings file your_app/settings.py, do not import Django’s settings in your_app/__init__.py with

from django.conf import settings

since that will make your_app.settings ambiguous. It may point to django.conf.settings when your_app.settings is not yet imported, or when it is imported, it will point to module defined by your_app/settings.py.

class shuup.apps.AppConfig(*args, **kwargs)

Bases: django.apps.config.AppConfig

default_settings_module = '.settings'

Name of the settings module for this app

required_installed_apps = ()

Apps that are required to be in INSTALLED_APPS for this app

This may also be a dict of the form {app_name: reason} where the reason will then be listed in the ImproperlyConfigured exception.

provides = {}

See /provides for details about the provides variable.

get_default_settings_module()

Get default settings module.

Returns:the settings module. Raises:ImportError if no such module exists.

shuup.apps.get_known_settings()

Get all settings known to Shuup.

Return type:Iterable[Setting]