It’s easy, no rocket-scientist needed.
We suggest you just take XStatic-jQuery package as a template and do these steps:
There are 2 names involved and you should follow these rules:
Note: if you are not packaging original files, but modified files, then you must use a name that makes this fact obvious.
VERSION - as you are just repackaging another project, you should use the upstream version number (or at least something closely related to it).
Some projects do not have good version numbers, make the best of it:
E.g. upstream version: 2010-12-31, XStatic-FooBar version: 2010.12.31
BUILD - as you maybe do not get packaging right on the first try, you’ll want to enumerate your builds: 0, 1, 2, ...
PACKAGE_VERSION - is automatically computed from VERSION . BUILD.
It is suggested that you only package files that are useful for Python projects, because XStatic packages will be only used by them. No need for PHP, ASP, Java, etc. related files.
If you package files that are somehow “compiled/compressed” versions, we suggest you only package the files needed for production usage, not the source code.
If the original download archive has the files needed for production in some subdirectory, we suggest you strip the directory hierarchy and just put the production files/directories into xstatic/pkg/foobar/data/.
If your files are available via a public CDN (Content Distribution Network), you can give the URLs via the locations metadata.
If you do not have a CDN for the files, just use locations = {}.
You should put your XStatic-FooBar package under same license as the upstream FooBar package. This avoids licensing complications and is also appropriate because you only added a little metadata anyway.
If you are maintaining packages for some other packaging system, like .deb or .rpm, this section is for you.
When designing XStatic stuff, we had YOU in mind! :)
But not only you, we also had in mind that there is no packaging system on Windows and that developers or virtualenv users rather like setuptools, distribute and pip.
Because of this, we did not want to rely on any mechanism that might be not available in some scenario - thus, after files are installed, we only use Python features (like importing from a installed python package, using __file__ to find out the path/filename, etc.).
You, as a package maintainer are interested in avoiding duplication, so that if you need to do a security update, you only need to fix in one place.
XStatic-* packages support this. If you do not want to heavily patch some Python software that uses XStatic ressource packages, you can alternatively just package the XStatic resource packages for your package system.
In case that would add duplication (because you already have a package that provides the same static files), you can simply remove the static files below data/ from the XStatic ressource package and adjust the path/filename so it points to the files provided by that other package.
E.g. for the XStatic-jQuery package, change:
BASE_DIR = join(dirname(__file__), 'data')
To:
BASE_DIR = '/usr/share/javascript/jquery'
Of course you need to make sure that the files at the location you point to are the same as the ones the XStatic ressource package provides below the data/ directory.
In your package dependencies for your repackaged XStatic ressource package you would then just require (depend on) the package providing these files.