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 > just bundles of css, javascript, images, fonts, etc. that are resources > 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 > > BOWER_COMPONENTS_ROOT to '/usr/lib/javascript/' or wherever. > > s/lib/share/ > > However, I'm almost sure that wont be enough to make it work. For > example, in Debian, we have /usr/share/javascript/angular.__js, not just > /usr/share/javascript/angular. So django-bower would be searching on the > 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 > packagers. > > 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... Cheers, Thomas Goirand (zigo) _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev