Open Stack

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 <r1chardj0n3s at gmail.com<mailto:r1chardj0n3s at gmail.com>>
Reply-To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Date: Monday, January 5, 2015 at 2:08 AM
To: OpenStack List <openstack-dev at lists.openstack.org<mailto:openstack-dev at lists.openstack.org>>
Subject: Re: [openstack-dev] [horizon] static files handling, bower/



On Mon Jan 05 2015 at 7:59:14 PM Radomir Dopieralski <openstack at sheep.art.pl<mailto:openstack at 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
> <openstack at sheep.art.pl<mailto:openstack at sheep.art.pl> <mailto:openstack at sheep.art.pl<mailto:openstack at 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