shoop.apps package

Submodules

shoop.apps.provides module

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

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

See also

See The Provides system for further information about the Provides system.

shoop.apps.provides.clear_provides_cache()

shoop.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]

shoop.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]

shoop.apps.provides.get_identifier_to_spec_map(category)

shoop.apps.provides.get_identifier_to_object_map(category)

shoop.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.

shoop.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

shoop.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]

shoop.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.

shoop.apps.settings module

shoop.apps.settings.collect_settings_from_app(app_config)

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

shoop.apps.settings.get_known_settings()

Get all settings known to Shoop.

Return type:Iterable[Setting]

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

Bases: object

shoop.apps.settings.validate_templates_configuration()

Validate the TEMPLATES configuration in the Django settings.

Shoop’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:

shoop.apps.settings.reload_apps()

Module contents

Shoop Application API

Every Shoop Application should define an app config class derived from shoop.apps.AppConfig.

Settings

To define settings for a Shoop 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 shoop.core.settings.

Naming Settings

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

1. Each setting should be prefixed with the string SHOOP_
2. Boolean toggle settings should have a verb in imperative mood as part of the name, e.g. SHOOP_ALLOW_ANONYMOUS_ORDERS, SHOOP_ENABLE_ATTRIBUTES or SHOOP_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. SHOOP_PRICING_MODULE_SPEC.
4. Setting names do NOT have to be prefixed with the application name. For example, SHOOP_BASKET_VIEW_SPEC which is not prefixed with SHOOP_FRONT even though it is from shoop.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 shoop.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 The Provides system 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

shoop.apps.get_known_settings()

Get all settings known to Shoop.

Return type:Iterable[Setting]