Now we have a way to publish and use Bower components. But you probably also develop your own front-end code: we call these “local components”. BowerStatic also helps with that. For this it is important to understand that locally developed code has special caching requirements:
When you release a local component, you want it to be cached infinitely just like for Bower components.
When later a new release is made, you want that cache to be invalidated, and not force end-users to do a shift-reload to get their browser to load the new version of the code.
We can accomplish this behavior by using a version number in the URL, just like for Bower components.
XXX one way to release a local component would be to release it as a bower component at this point. But this may be cumbersome for code maintained as part of Python package.
When you develop a local component, you want the cache to be invalidated as soon as you make any changes to the code, so you aren’t forced to do shift-reload during development. A simple reload should refresh all static resources.
A way to look at this is that you want the system to make a new version number for each and every edit to the local component.
To have local components, you first have to create a special local components registry:
local = bower.local_components('local', components)
You can have more than one local components registry, but typically you only need one per project.
The first argument is the name of the local components registry. It is used in the URL.
The second argument is a components object for a
directory, created earlier with
bower.components(). This makes all
those bower components available in the local component registry, so
that the local components can depend on them.
Note that the local components registry does not point to a
bower_components directory itself. Instead we register directories
for individual local components manually.
Here’s how we add a local component:
/path/to/directory/mycode directory should have a
bower.json file. BowerStatic uses
main for local
components like it uses them for third party Bower components. The
name of the component should be unique within the local registry, as
well as not conflict with any component in the Bower components
bower.components, you can use
to create a path relative to the calling module:
components = local.component( bowerstatic.module_relative_path('path/relative/to/calling/module'), version='1.1.0')
dependencies is also picked up from
bower.json, but unlike for
third party components these dependencies are not automatically
The version number is not picked up from
bower.json. Instead it is
passed through to the local component. This will make it possible to
support the right caching behavior. We go into detail about this
If you have a local component called
mycode, and there is a file
app.js in its directory, it is published under this URL:
To be able to include it, we can create an includer for the
include = local.includer(environ)
This includer can be used to include local components, but also the third-party components from the registry that the local components registry was initialized with.
You can now include
mycode like this:
Let’s consider versioning in more detail.
The version number is passed in when registering the local component. We want it to do the right thing with caching:
- When the application is deployed, we want the version number to be the version number of that application (or sub-package of that application), so that infinite caching can be used but the cache is automatically busted with an application upgrade.
- When the application is under development, we want the version number to change each time you edit the local component’s code, so that the cache is busted each time.
Versioning deployed applications¶
You can use the version of a Python application easily, as long as it
is packaged using
buildout, etc). You can retrieve its version number like this:
import pkg_resources version = pkg_resources.get_distribution('myproject').version
This picks up the version given in
Using this to obtain the version and passing it into
local.component() is enough to make sure the cache is busted when
you make a release of your application.
Versioning during development¶
We have to make sure the cache is busted automatically during
development as well. For that we have to turn on BowerStatic’s
development mode. You can do this by passing
None as the version
This causes the version to be automatically determined from the code in the package, and be different each time you edit the code. Since the version is included in the URL to the package, this allows you to get the latest version of the code as soon as you reload after editing a file. No shift-reloads needed to reload the code!
Putting it all together¶
Development mode is relatively expensive, as BowerStatic has to
monitor the local directory for any changes so it can update the
version number automatically. You should therefore make sure it is
only enabled during development, not during deployment. When your
application is deployed you need to pass in a real version number, for
instance the one you pick up using
pkg_resources as described
If your application has a notion of a development mode that you can
somehow inspect during run-time, you can write a version function that
None in development mode and otherwise
returns the application’s version number. This ensures optimal caching
behavior during development and deployment both. Here’s what this
function could look like:
def get_version(): if is_devmode_enabled(): # app specific API return None return pkg_resources.get_distribution('myproject').version
You can then register the local component like this: