From: mrunge(a)matthias-runge.de
To: <devel(a)lists.fedoraproject.org>
Date: 01/21/2014 15:38
Subject: Re: Best Practices for Django App Packaging
Sent by: devel-bounces(a)lists.fedoraproject.org
On 01/21/2014 05:22 PM, John.Florian(a)dart.biz wrote:
>> [1]
>>
http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/
>> openstack-dashboard.conf
>> [2]
>>
http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/
>> openstack-dashboard-httpd-2.4.conf
>> [3]
>>
http://pkgs.fedoraproject.org/cgit/python-django-horizon.git/tree/
>> python-django-horizon.spec
>
> Thanks Matthias! That's quite a complicated example, although I can
see
> there's much I can learn from it. Unfortunately, it's
not the ideal
> example because it moves everything that setup.py builds into
> /usr/share/openstack-dashboard. I need to keep stuff under
> /usr/lib/pythonX.Y/site-packages so that the other, non-Django, parts
> continue to work as expected. (I suppose I could just relocate the
> Django-parts of the build, but sounds like it will break more things
> that it will help.)
Yes, you're right. It's not the ideal and simple example.
On the other side, it doesn't matter if you put all that stuff to
/usr/share or to %{python_sitelib}
Basically, you just need the two files. Stephen had another, more simple
example. This gets the job done. For most real world deployments you'd
need some more config changes (database, caching, ssl, and more
securing).
Matthias
Yup, I'm seeing it now. I realize sqlite is normally used for production
deployments, but in my case I would have been totally fine with it since I
know the number of "user" connections is always going to be less than 20
or so: one real human on rare occasions and the rest from machines that
are almost always going to get a cached page since they're each asking
once a minute for their own same page. However, SELinux made me adopt the
better practice of using Postgresql since all the policy is there for
that. :-)
I've got a deployed (test) setup roughly working now. Next step is to
clean up the "hard to maintain & it's fragile" aspects. I will probably
wind up doing as openstack-dashboard does and moving some of the python
package/modules out of /usr/lib/pythonX.Y and into /usr/share/my_app since
the rpm spec can do that much smartly. Then my puppet manifests can refer
to things that aren't such moving targets.
I largely want to avoid a big mess of figuring out how to migrate the
deployed instance to new hosts as Fedora releases come out. (As a rule,
we never upgrade; just reinstall with much help from puppet. Think of it
as a fire drill.) Hopefully I'll get to keep playing with Django in the
future so it all doesn't become foreign 6 months from now.
Thanks to all for the pointers. They've been a big help.
--
John Florian