I think the only outstanding question is how developers and non-packagers
populate the bower_components directory - that is, how is bower expected to
be available for them?
I think following the Storyboard approach is a good idea: isolate a
known-working node/bower environment local to horizon which is managed by
tox - so to invoke bower you run "tox -e bower <command>". No worries about
system installation or compatibility, and works in the gate.
Horizon installation (whenever a pip install would be invoked) would then
also have a "tox -e bower install" invocation.
Storyboard[1] uses a thing called nodeenv[2] which is installed through pip
/ requirements.txt to control the node environment. It then has bower
commands in tox.ini[3] (though I'd just have a single "bower" environment
to implement the tox command I suggest above.
Richard
[1] https://wiki.openstack.org/wiki/StoryBoard
[2] https://pypi.python.org/pypi/nodeenv
[3]
https://git.openstack.org/cgit/openstack-infra/storyboard-webclient/tree/tox.ini
On Tue Jan 06 2015 at 11:42:17 AM Tripp, Travis S <travis.tr...@hp.com>
wrote:
> 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
> -d...@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
>
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
