[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Uploading python-xstatic-* packages in Debian

Just a quick explanation of what I'm doing with the python-xstatic-*
packages here. I've thought about how to do it best for a long time.

Upstream for the OpenStack dashboard (otherwise called Horizon) decided
(very rightly) that holding embedded copies of javascript files was a
bad idea. So they now rely on Python module XStatic-* instead of their
embedded copy. Each of these small python modules contain embedded
copies of static files, like javascript, .css, or the like. When
upstream runs tests using PyPi, it downloads the Python module in a
virtualenv, then uses whatever static file(s) comes with the Python module.

In Debian, Horizon will depend on python-xstatic-* packages. Most of the
time, when the static files are available in Debian, the resulting
package do *not* embed a copy (I delete it from the resulting .deb file,
depend on the libjs-* corresponding package, and either symlink to the
target file or patch the xstatic/pkg/*/__init__.py which is what
upstream recommends doing).

Note that the XStatic python modules aren't just meta packages, they
also offer a mechanism for a Python script to discover where to find a
given static file in the system (which really, isn't obvious, as the
Debian archive is a bit messy in this regard, especially when dealing
with static files that aren't javascript like .css or .less files).

As for the licensing, note that each XStatic package follows the
upstream licensing of the files it embeds (which IMO, is a very good

It is also worth noting that the Debian package version for XStatic
modules is following the static file package version. For example, even
though upstream released XStatic-JQuery, the Debian package
version is, to match the version number of libjs-jquery.

Also, to have no surprise, I sometimes intentionally restricted version
numbers. For example: python-xstatic-angular has "Depends:
libjs-angularjs (<< 1.2.17), libjs-angularjs (>= 1.2.16)", just to avoid
surprises. If one day, it becomes uninstallable, then I will know the
python-xstatic package will have to be updated.

For some XStatic packages, the embedded static files are not present in
Debian. That is the case for example with python-xstatic-hogan,
python-xstatic-jasmine, or python-xstatic-bootstrap-scss. For the above
3 packages, the upstream source code is part of a much larger project.
See for example bootstrap-scss, which comes with a huge Ruby framework.
I have no intention to package all of that...

As I know very little about packaging of some upstream code (for
example, I have never maintained ruby or nodejs packages), and that I
don't need them anyway (I only need a few javascript files from them, I
will have no use of Ruby or nodejs code), then I decided to *not*
package the full upstream package, and leave the embedded copy inside
the python-xstatic-* packages. This is until someone needs the full
upstream package, at which point I will remove the embedded copy, and
point to the relevant files inside the recently uploaded package.

Also, for the sake of simplicity, I'm not removing the embedded copy of
static files from the XStatic source package (as long as these are DFSG
compliant: I had to remove one of them because it contained the .min.js
which isn't desirable).

If you want to package one of the files which I will embed in
python-xstatic-* packages, just let me know, so that we keep only a
single copy in Debian.

As for other Python packages for which upstream is embedding static file
copies, I would recommend you, as a maintainer, to point to the relevant
packages in PyPi to upstream, so they can adopt the same technique.

My only concern with all of this, is that it will produce a lot of
micro-packages. Though I believe the benefits of having a clean system
to remove embedded copies and having a clean way to find these files on
a Debian system outweighs the added load on our infrastructure.

I thought it was best to inform my fellow Debian contributors about what
I was doing, so that there's no surprise. Also, I would welcome
suggestions if you have any.


Thomas Goirand (zigo)

Reply to: