Best Practices for Django App Packaging

[Stephen Gallagher]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 01/21/2014 02:12 PM, John.Florian at dart.biz wrote:
>> From: sgallagh at redhat.com To: Development discussions related to
>> Fedora
> <devel at lists.fedoraproject.org>
>> Date: 01/21/2014 13:24 Subject: Re: Best Practices for Django App
>> Packaging Sent by: devel-bounces at lists.fedoraproject.org
>> 
> On 01/21/2014 11:22 AM, John.Florian at dart.biz wrote:
>>> On 01/21/2014 03:45 PM, John.Florian at dart.biz wrote:
>>>> While I've been packaging Python apps for Fedora for a long 
>>>> time, I'm a complete novice to Django.  I've just completed
>>>> my first app (using the built-in development server) and now
>>>> want to get it packaged.  Thus far I've followed my normal
>>>> model of using setuptools so that everything very cleanly
>>>> lands in /usr/lib/python2.7/site-packages/my_package.  My
>>>> Django app is under there, along with other related Python
>>>> modules that are used independently of the Django app.
>>>> 
>>>> I'm not finding any docs in the Fedora package guidelines
>>>> and am unaware of existing packages that might serve as
>>>> excellent examples.  My web searches are turning up lots, but
>>>> nothing much specific to Fedora.
>>>> 
>>>> At the moment, I'm particularly struggling with how to make
>>>> my /etc/httpd/conf.d/myapp.conf point to my 
>>>> /usr/lib/python2.7/site-packages/my_package/my_site/wsgi.py
>>>> in a good generic RPM spec sense.  I'd rather not hard-code
>>>> the Python version in myapp.conf.
>>>> 
>>>> Any pointers would be greatly appreciated.
>>>> 
>>> If you want an exampple, please look at openstack-dashboard:
>>> [1] is the config file to be dropped at /etc/httpd/conf.d (for 
>>> httpd-2.2) or [2] for httpd-2.4
> 
>>> The spec is here[3] for reference.
> 
>>> HTH, Matthias
> 
> 
>>> [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.)
> 
> 
> Another example you may want to take a look at is ReviewBoard,
> which is pretty straightforward.
> 
> http://pkgs.fedoraproject.org/cgit/ReviewBoard.git/tree/ReviewBoard.spec
>
> 
> 
> 
> Thank you too Stephen!  That indeed does look much more similar. 
> Although I don't see any Apache httpd config in the package.
> Reading The Fine Manual briefly looks like it relies on 'rb-site
> install' to do this part.  I was hoping to find an example where
> the RPM spec dropped a Django app setup right into
> /etc/httpd/conf.d -- in other words, a package that just assumes
> you will use Apache httpd, maybe even creates an empty sqlite db so
> things are just ready to run with a httpd restart.
> 
> I may be just trying to do too much in my spec and perhaps should
> rely on puppet to do the deployment and integration work.


Well, part of the reasoning here is that Django supports "sites".
First of all, there's no default configuration that will likely ever
work, because they need to create a custom Apache configuration for
each hostname.

Furthermore, you can install multiple different sites on the same
machine in different URL paths.

Finally, nobody uses SQLite for a real-world deployment (it's not
built for that). It's good for development/testing, but it's not a
real deployment case.


So yes, the real expectation here should be that you deploy the bits
you need and configure them with "an appropriate tool".
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iEYEARECAAYFAlLezk0ACgkQeiVVYja6o6PwEwCfZ1OFqYkG+x9WpD1MNalGt3Ky
A+gAoKKggtn4GMGuieq2FaxQviKffx+m
=WGKD
-----END PGP SIGNATURE-----