settings.py, settings.py, catalog, and catalog
Gabriel Farrell
my machine. First, there are two settings.py files, in catalog/ and
in catalog/catalog/. AFAIK, a settings.py file at the app level is
unusual for Django. Also, most of the settings are duplicated in both
files and it's not clear which overrides the other. Any education on
the history of how things got to be this way would be most
appreciated.
Second, the existence of an app of the same name as the project
("catalog" and "catalog") is also odd. Last I checked, Django
wouldn't allow you to create an app of the same name as the project
via `python manage.py startapp [app_name]`. I think we might avoid
some potential pitfalls if we rename either the project or app.
As long as I'm going on about major overhalls in design (:-), it seems
to me that everything in config.py could be included in (one)
settings.py, maybe under a "Solr" section, as long as there are no
variable collisions. It may not be a good idea to pollute the Django
settings in that way, however.
Finally, there are some bits in the code related to Python coding
style that rub me the wrong way, such as camelCase and extraneous
whitespace, that I'd be into cleaning up. Is anyone really attached
to the code style as it is now? I realize this is a pretty nit-picky
when there are bigger things to worry about (upcoming Helios merge,
etc.), but it's something I'd do anyway as I start to work with the
code and I wanted to make sure I'm not stepping on any toes.
Gabe
Dan Scott
Gabe:
I'm with you 100%. The duplicated settings.py and nested
catalog/catalog structure didn't make a whole lot of sense to me to
begin with when I first started playing with the code, but I became so
focused on just making it work that I kind of rolled with it.
If you want to make the code more pythonic and more Django-ish, I for
one certainly welcome any attention you care to lavish on the code!
I'll commit the Helios branch (shout-out to everyone out there: Helios
was Casey Durfee's evolution of the code base that begat FBO, and a
while back he agreed to unleash the code unto the world, giving me
license to do so if I so desired ... so it shall be done!) and maybe
it would make sense to cherry-pick the best bits of that branch (tag
clouds anyone?) before attacking too many python style issues :)
Welcome to the project, Gabe. I'm going to give you committer access
momentarily...
--
Dan Scott
Laurentian University
Gabriel Farrell
Is this a full merge? That is, will Helios continue separately? I
guess what I'm
getting at is this: could we change the name of FBO to Helios?
> Welcome to the project, Gabe. I'm going to give you committer access
> momentarily...
>
Great, thanks. And congrats, Dan and Mike, on the article!
Dan Scott
Hi Gabe:
I've sent a separate email to Casey to ask if he's okay with us using
the name "Helios" for a "Fac-Back-OPAC 2.0: The Refactoring"
I've also updated the f-b-o trunk with some additional settings to
reflect recent requirements in Django trunk; LocaleMiddleware now
appears to demand the use of django.contrib.sessions, which means we
have to have a database configured in settings.py (so of course I
configured both settings.py files); and we'll have to add the "python
manage.py syncdb" step to prep the database with the required schema.
I'm just trying to get f-b-o trunk back into step with django trunk,
but based on our irc chat I believe you have plans for something
bigger... /me steps back from the mic