What Radomir proposes looks like it would greatly ease the process I am still
going through to get the latest angular available to Horizon for current
development. At the time of writing this, I’m still trying to get the updated
library through. I hit a rather difficult workflow:
1. Packaged the latest into Xstatic-Angular-1.3.7
2. Submitted patch which deprecated the separate older
xstatic-angular-cookies and xstatic-angular-mock packages
3. Reviewed and approved (after correcting an initial mis-repackaging)
4. Radomir released to Pypi
This was pretty easy and not too hard. Not too much to complain about.
However, now, to get Horizon to use it, I have to get that into global
requirements. Since I’m deprecating old packages I got stuck in a sort of ugly
dependency path. I couldn’t remove the cookies and mock libraries from the
global requirements patch that added the new 1.3.7 package because of horizon
still referencing the deprecated packages. And, when I did it anyway, the
integration tests failed due to horizon being dependent on something not in
global requirements. So, now, as far as I can tell we have to jump through the
following hoops:
1. Global requirements patch to add angular 1.3.7
* Verify check / recheck fun
* Reviewed and approved
* Gate check / recheck fun
2. Horizon patch to update to angular 1.3.7 and remove deprecated mock and
cookies packages
* Verify check / recheck fun
* Reviewed and approved
* Gate check / recheck fun
3. Global requirements patch to remove deprecated mock and cookies
* Verify check / recheck fun
* Reviewed and approved
* Gate check / recheck fun
Don’t get me wrong, I really do think the gate is brilliant and am all for a
review / approval process, but this does seem excessive for a UI library that
should only be used by Horizon. Is there some other reason that this should
have to go through global requirements?
Thanks,
Travis
From: Richard Jones <r1chardj0...@gmail.com<mailto:r1chardj0...@gmail.com>>
Reply-To: OpenStack List
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Date: Monday, January 5, 2015 at 2:08 AM
To: OpenStack List
<openstack-dev@lists.openstack.org<mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [horizon] static files handling, bower/
On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski
<openst...@sheep.art.pl<mailto:openst...@sheep.art.pl>> wrote:
On 05/01/15 00:35, Richard Jones wrote:
> On Mon Dec 22 2014 at 8:24:03 PM Radomir Dopieralski
> <openst...@sheep.art.pl<mailto:openst...@sheep.art.pl>
> <mailto:openst...@sheep.art.pl<mailto:openst...@sheep.art.pl>>> wrote:
>
> On 20/12/14 21:25, Richard Jones wrote:
> > This is a good proposal, though I'm unclear on how the
> > static_settings.py file is populated by a developer (as opposed to a
> > packager, which you described).
>
> It's not, the developer version is included in the repository, and
> simply points to where Bower is configured to put the files.
> So just to be clear, as developers we:
>
> 1. have a bower.json listing the bower component to use,
> 2. use bower to fetch and install those to the bower_components
> directory at the top level of the Horizon repos checkout, and
> 3. manually edit static_settings.py when we add a new bower component to
> bower.json so it knows the appropriate static files to load from that
> component.
>
> Is that correct?
>
> The above will increase the burden on those adding or upgrading bower
> components (they'll need to check the bower.json in the component for
> the appropriate static files to link in) but will make life easier for
> the re-packagers since they'll know which files they need to cater for
> in static_settings.py
Well, I expect you can tell Bower to put the files somewhere else than
in the root directory of the project -- a directory like ``bower_files``
or something (that directory is also added to ``.gitignore`` so that you
don't commit it by mistake). Then only that directory needs to be added
to the ``static_settings.py``. Of course, you still need to make all the
``<script>`` links in appropriate places with the right URLs, but you
would have to do that anyways.
Bower installs into a directory called bower_components in the current
directory, which is equivalent to your bower_files above.
Let's look at an example. Suppose you need to a new JavaScript library
called "hipster.js". You add it to the ``bower.json`` file, and run
Bower. Bower downloads the right files and does whatever it is that it
does to them, and puts them in ``bower_files/hipster-js``. Now you edit
Horizon's templates and add ``<script src="{{ STATIC_URL
}}/hipster-js/hipster.js">`` to ``_scripts.html``. That's it for you.
Since your ``static_settings.py`` file already has a line:
('', os.path.join(BASE_DIR, '/bower_files')),
in it, it will just work.
Yep, except s/bower_files/bower_components :)
Now, suppose that a packager wants to package this for, say, Debian. And
suppose that Debian has "hipster.js" packaged, except it was called
"bro.js" before, and they left the old name for compatibility reasons.
He will look at the change history to the ``bower.json`` and the
``_scripts.html`` files, take the ``static_settings.py`` file for his
distribution, and add a line:
('hipster-js/hipster.js', '/usr/lib/js_libraries/bro_js/bro.js')
Ah! I had forgotten about that feature. Yep, all good :)
Richard
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
