Open Stack

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)