The latest source is not on GitHub, it is on pagure.io. You can find it at https://pagure.io/fedora-hubs
Install fedora dependencies:
$ sudo dnf install gcc gcc-c++ sqlite-devel
Hubs should work on either python2 or python3. These instructions will show the way for python2 only, though.
Setup a python virtualenv:
$ sudo dnf install python-virtualenvwrapper $ mkvirtualenv hubs
Install the dependencies from PyPI:
$ pip install -r requirements.txt
Give fedora-hubs some FAS credentials. It's going to need these to query FAS
for information about other users. When we deploy this thing to production,
we'll use a system account for this but for now, just use your personal
account. Copy the following into fedmsg.d/fas_credentials.py
:
config = { 'fas_credentials': { 'username': 'YOUR_FAS_USERNAME_GOES_HERE', 'password': 'YOUR_FAS_PASSWORD_GOES_HERE', } }
With that, try running the app with:
$ PYTHONPATH=. python populate.py # To create the db $ PYTHONPATH=. python hubs/app.py # To run the dev server
And then navigate to http://localhost:5000/designteam
If you want to test it with 8 worker threads, try gunicorn
:
$ pip install gunicorn $ gunicorn -w 8 hubs.app:app -t 60 --reload
Hacking on Widgets one-liner:
$ rm /var/tmp/hubs.db; PYTHONPATH=. python populate.py; gunicorn -w 8 hubs.app:app
There's no authn or user information at all currently. There are only:
How things are currently (they don't have to stay this way):
You write a new widget in the hubs/widgets/
directory and must declare it
in the registry dict in hubs/widgets/__init__.py
.
In order to be valid, a widget must have:
data(request, session, widgets, **kwargs)
function that returns a
jsonifiable dict of data. This will get cached -- more on that later.template
object that is a jinja2 template for that widget.chrome
decorator.This isn't implemented yet, but they're going to need:
should_invalidate(message, session, widget)
function that will be used to
potentially invalidate the widget's cache. That function will get called by
a backend daemon listening for fedmsg messages so when you update your group
memberships in FAS, a fedmsg message hits the fedora-hubs backend and returns
True if the lookup value should be nuked/refreshed in memcached (or some
other store).Furthermore, a proposal:
The template per-widget is currently held and rendered server-side with jinja2. This is how all our apps do it, more or less.
We might want to consider using handlebars.js for our templates instead and rendering all of the widgets asynchronously on the client. It could be cool, but is new-ground for our team.
Still more proposals:
As an aside, it became clear to me when making the diagram in the next section that, if we use handlebars.js and get rid of the server-side template rendering, then 1) the data returned by AJAX requests at page load and 2) the data pushed by the EventSource server can be the exact same data. It will simplify and streamline the responsibilities of the pieces if the backend is worried only about these per-widget JSON responses.
This is more "proposal" territory. None of this is implemented, but here are some more details on how the whole thing should work together.
A diagram of component interactions
Let's talk through how data will flow through the system by asking what happens when a user requsts their main hubs page:
data(...)
function of that widget to get the
response ready. It is stuffed in memcached for later access and returned.Later, what happens when a trac ticket is filed that should show up in some widget on their page?
data(...)
on them.What happens when the user is viewing the design team hub and simultaneously, an admin changes the configuration of a widget on that page?
data(...)
on the widget.