<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 21 November 2014 16:12, Thomas Goirand <span dir="ltr"><<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 11/21/2014 10:52 AM, Richard Jones wrote:<br>
> On 11/18/2014 04:22 PM, Radomir Dopieralski wrote:<br>
> > If we use Bower, we don't need to use Xstatic. It would be pure<br>
> > overhead. Bower already takes care of tracking releases and versions,<br>
> > and of bundling the files. All we need is a simple line in the<br>
> > settings.py telling Django where it puts all the files -- we don't<br>
> > really need Xstatic just for that. The packagers can then take those<br>
> > Bower packages and turn them into system packages, and just add/change<br>
> > the paths in settings.py to where they put the files. All in one<br>
> > place.<br>
><br>
> The issue is that there's often not just a single path, but a full<br>
> directory structure to address. That is easily managed with a Debian<br>
> xstatic package, not sure how it would be with Bower.<br>
><br>
><br>
> I'm not sure what the difference is (unless it's just related to the<br>
> Debian-specific historical issue you raise below). xstatic and bower are<br>
> remarkably similar a directory to be packaged and some meta-data<br>
> describing it.<br>
<br>
</span>Let me explain again then.<br>
<br>
Let's say there's python-xstatic-foo, and libjs-foo in Debian. If the<br>
directory structure of libjs-foo is very different from xstatic-foo, I<br>
can address that issue with symlinks within the xstatic package. Just<br>
changing the BASE_DIR may not be enough, as libjs-foo may have files<br>
organized in a very different way than in the upstream package for foo.<br></blockquote><div><br></div><div>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.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">> By the way, I went into <a href="http://bower.io" target="_blank">bower.io</a> <<a href="http://bower.io" target="_blank">http://bower.io</a>> as I wanted to<br>
<span class="">> have a look. How do I<br>
> download a binary package for let's say jasmin? When searching, it<br>
> just links to github...<br>
><br>
><br>
> Again; bower is not npm! Jasmine is a command-line program which is<br>
> packaged by npm. Bower packages bundles of stuff that are included in<br>
> web applications. bower itself, a command-line tool, is packaged by npm,<br>
> but itself manages other packages which are not command-line things, but<br>
> just bundles of css, javascript, images, fonts, etc. that are resources<br>
> for web applications to use.<br>
<br>
</span>Sure. But how do I download a bower package then?<br></blockquote><div><br></div><div>I'm not sure I understand the meaning behind this question. "bower install angular" downloads a bower package called "angular".</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">> This would only work if upstream package directory structure is the same<br>
> as the one in the distribution. For historical reason, that's<br>
> unfortunately often not the case (sometimes because we want to keep<br>
> backward compatibility in the distro because of reverse dependencies),<br>
> and just changing the path wont make it work.<br>
><br>
> On 11/19/2014 03:43 AM, Richard Jones wrote:<br>
> > +1 to all that, except I'd recommend using django-bower to handle the<br>
> > static collection stuff. It's not documented but django-bower has a<br>
> > setting BOWER_COMPONENTS_ROOT which would make the above<br>
> transition much<br>
> > simpler. You leave it alone for local dev, and packagers setup<br>
> > BOWER_COMPONENTS_ROOT to '/usr/lib/javascript/' or wherever.<br>
><br>
> s/lib/share/<br>
><br>
> However, I'm almost sure that wont be enough to make it work. For<br>
</span>> example, in Debian, we have /usr/share/javascript/angular.__js, not just<br>
<span class="">> /usr/share/javascript/angular. So django-bower would be searching on the<br>
> wrong path.<br>
><br>
><br>
> That is unfortunate. It may be that Debian therefore has to special-case<br>
> angular to handle that case.<br>
<br>
</span>I wasn't making a point about Angular here. It's a general issue we have<br>
to take care of addressing correctly.<br>
<span class=""><br>
> I think the general idea of following the component pattern set by bower<br>
> (separate directories with no risk of conflicts, and using the<br>
> bower.json meta-data to allow automatic configuration of the component)<br>
> is too good to dismiss though. Far less work for everyone, including<br>
> packagers.<br>
><br>
> Perhaps the new packages should have "bower" in their name?<br>
<br>
</span>There's already libjs-angularjs and a bunch of python-xstatic-angular<br>
packages in Debian. I'm not sure that it is necessary to *also* have a<br>
bower-angularjs packages. Why would I need to do that? Just for the<br>
.json file? If that's the case, then couldn't I just add the bower.json<br>
file in the existing libjs-* packages? I'm not sure I get the point here...</blockquote><div><br></div><div>The angular component that bower installs looks like this:</div><div><br></div><div><div><div>$ ls -CAF bower_components/angular</div><div>.bower.json<span class="" style="white-space:pre"> </span>angular-csp.css<span class="" style="white-space:pre"> </span>angular.min.js<span class="" style="white-space:pre"> </span>angular.min.js.map<span class="" style="white-space:pre"> </span>package.json</div><div>README.md<span class="" style="white-space:pre"> </span>angular.js<span class="" style="white-space:pre"> </span>angular.min.js.gzip<span class="" style="white-space:pre"> </span>bower.json</div></div></div><div><br></div><div>The bootstrap component looks like this:</div><div><br></div><div><div>$ ls -CAF bower_components/boot/</div><div>.bower.json<span class="" style="white-space:pre"> </span>LICENSE<span class="" style="white-space:pre"> </span>bower.json<span class="" style="white-space:pre"> </span>fonts/<span class="" style="white-space:pre"> </span>js/<span class="" style="white-space:pre"> </span>package.json</div><div>Gruntfile.js<span class="" style="white-space:pre"> </span>README.md<span class="" style="white-space:pre"> </span>dist/<span class="" style="white-space:pre"> </span>grunt/<span class="" style="white-space:pre"> </span>less/</div></div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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).</div><div><br></div><div>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).</div><div><br></div><div><br></div><div> Richard</div><div><br></div></div></div></div>