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.get_provide_specs_and_objects(category)[source]
Get a mapping of provide specs (“x.y.z:Q”) to their loaded objects (<class Q>).
- shuup.apps.provides.get_provide_objects(category)[source]
Get an iterable of provide objects for the given category.
- shuup.apps.provides.override_provides(category, spec_list)[source]
Context manager to override
provides
for a given category.Useful for testing.
- shuup.apps.provides.load_module(setting_name, provide_category)[source]
Load a module from a module setting.
The value of the setting must be a module identifier for the given provide category.
- shuup.apps.provides.load_modules(setting_name, provide_category)[source]
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.
- shuup.apps.provides.load_module_instances(setting_name, provide_category)[source]
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.get_known_settings()[source]
Get all settings known to Shuup.
- Return type:
Iterable[Setting]
- shuup.apps.settings.validate_templates_configuration()[source]
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:
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.
Each setting should be prefixed with the string
SHUUP_
Boolean toggle settings should have a verb in imperative mood as part of the name, e.g.
SHUUP_ALLOW_ANONYMOUS_ORDERS
,SHUUP_ENABLE_ATTRIBUTES
orSHUUP_ENABLE_MULTIPLE_SHOPS
.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
.Setting names do NOT have to be prefixed with the application name. For example,
SHUUP_BASKET_VIEW_SPEC
which is not prefixed withSHUUP_FRONT
even though it is fromshuup.front
application.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)[source]
Bases:
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.