Re: Best Practices for Django App Packaging

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> From: mrunge@xxxxxxxxxxxxxxxxx
> To: <devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Date: 01/21/2014 15:38
> Subject: Re: Best Practices for Django App Packaging
> Sent by: devel-bounces@xxxxxxxxxxxxxxxxxxxxxxx
>
> On 01/21/2014 05:22 PM, John.Florian@xxxxxxxx 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

-- 
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux