Open Stack

On 21 November 2014 16:12, Thomas Goirand <zigo at debian.org> wrote:

> 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.
>

OK, so python-xstatic-foo can depend on libjs-foo and just symlink, fair
enough. I'm still not sure what makes bower unique in this respect,
although it'd be nice to avoid creating additional packages just to symlink
things around for bower, which I think is what you're getting at.


>     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?
>

I'm not sure I understand the meaning behind this question. "bower install
angular" downloads a bower package called "angular".


>     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...


The angular component that bower installs looks like this:

$ ls -CAF bower_components/angular
.bower.json angular-csp.css angular.min.js angular.min.js.map package.json
README.md angular.js angular.min.js.gzip bower.json

The bootstrap component looks like this:

$ ls -CAF bower_components/boot/
.bower.json LICENSE bower.json fonts/ js/ package.json
Gruntfile.js README.md dist/ grunt/ less/

Note that .bower.json may be ignored; it has the same contents as
bower.json, but is generated at install time by bower and contains
additional meta-data which isn't important to using the package; the
bower.json file is authored by the person who created the bower component.

The general pattern follows the above: each component gets its own
subdirectory which grants it its own filesystem namespace, but also means
the interface for a web application is identical in each case: look for the
bower.json file in the component subdirectory, and look for the "main"
property in there to determine the files to link into the application's
HTML.

That json file is one of the primary reasons for using bower. xstatic has
*some* of the same metadata, but doesn't include the entry point, sadly
(though my bower-to-xstatic tool does copy it over).

So mostly it's for the json file, yes, but it also means we avoid any
potential filename collisions between components (when, say, several have
"js" subdirectories).


      Richard
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20141121/12bde495/attachment.html>