[openstack-dev] [Horizon] the future of angularjs development in Horizon
zigo at debian.org
Fri Nov 21 05:12:38 UTC 2014
On 11/21/2014 10:52 AM, Richard Jones wrote:
> On 11/18/2014 04:22 PM, Radomir Dopieralski wrote:
> > If we use Bower, we don't need to use Xstatic. It would be pure
> > overhead. Bower already takes care of tracking releases and versions,
> > and of bundling the files. All we need is a simple line in the
> > settings.py telling Django where it puts all the files -- we don't
> > really need Xstatic just for that. The packagers can then take those
> > Bower packages and turn them into system packages, and just add/change
> > the paths in settings.py to where they put the files. All in one
> > place.
> The issue is that there's often not just a single path, but a full
> directory structure to address. That is easily managed with a Debian
> xstatic package, not sure how it would be with Bower.
> I'm not sure what the difference is (unless it's just related to the
> Debian-specific historical issue you raise below). xstatic and bower are
> remarkably similar a directory to be packaged and some meta-data
> describing it.
Let me explain again then.
Let's say there's python-xstatic-foo, and libjs-foo in Debian. If the
directory structure of libjs-foo is very different from xstatic-foo, I
can address that issue with symlinks within the xstatic package. Just
changing the BASE_DIR may not be enough, as libjs-foo may have files
organized in a very different way than in the upstream package for foo.
> By the way, I went into bower.io <http://bower.io> as I wanted to
> have a look. How do I
> download a binary package for let's say jasmin? When searching, it
> just links to github...
> Again; bower is not npm! Jasmine is a command-line program which is
> packaged by npm. Bower packages bundles of stuff that are included in
> web applications. bower itself, a command-line tool, is packaged by npm,
> but itself manages other packages which are not command-line things, but
> for web applications to use.
Sure. But how do I download a bower package then?
> This would only work if upstream package directory structure is the same
> as the one in the distribution. For historical reason, that's
> unfortunately often not the case (sometimes because we want to keep
> backward compatibility in the distro because of reverse dependencies),
> and just changing the path wont make it work.
> On 11/19/2014 03:43 AM, Richard Jones wrote:
> > +1 to all that, except I'd recommend using django-bower to handle the
> > static collection stuff. It's not documented but django-bower has a
> > setting BOWER_COMPONENTS_ROOT which would make the above
> transition much
> > simpler. You leave it alone for local dev, and packagers setup
> However, I'm almost sure that wont be enough to make it work. For
> wrong path.
> That is unfortunate. It may be that Debian therefore has to special-case
> angular to handle that case.
I wasn't making a point about Angular here. It's a general issue we have
to take care of addressing correctly.
> I think the general idea of following the component pattern set by bower
> (separate directories with no risk of conflicts, and using the
> bower.json meta-data to allow automatic configuration of the component)
> is too good to dismiss though. Far less work for everyone, including
> Perhaps the new packages should have "bower" in their name?
There's already libjs-angularjs and a bunch of python-xstatic-angular
packages in Debian. I'm not sure that it is necessary to *also* have a
bower-angularjs packages. Why would I need to do that? Just for the
.json file? If that's the case, then couldn't I just add the bower.json
file in the existing libjs-* packages? I'm not sure I get the point here...
Thomas Goirand (zigo)
More information about the OpenStack-dev