In short, there's not much cataloging going on yet in Kochief, so
you're not duplicating any prior effort. Glad to hear you got Kochief
up and running, and that you're beginning to feel your way around. I'm
happy to look over any code you want help integrating.
> --
> You received this message because you are subscribed to the Google
> Groups "Kochief" group.
> To post to this group, send email to koc...@googlegroups.com
> To unsubscribe from this group, send email to
> kochief+u...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/kochief
Otherwise, looks like a good start for your needs.
Sorry no one got back on the MARC encoding issues. They can be hairy.
I don't have any experience with the LoC MARC dumps, but if it
continues to be a problem post a detailed message to the list and
maybe someone here can help.
Looks better. It's great to be able to run "python manage.py syncdb &&
python manage.py runserver" in a freshly-cloned repo and see a working
project. You might still want to add an .hgignore with lines as
follows:
syntax: glob
*.pyc
bookshare/.DdBb
> Though I wonder if having the project in a directory called bookshare is
> really the right solution. My version of kocief is in
> ~/library/kochief/kochief/kochief/
>
> (i created one to clone into, clone created one and one was in the repo)
>
> with this method, would it be possible/convinient to be pulling changes in
> from django-ils and kochief on a system where both are being used in
> conjunction? then you have ~/library/kochief/kochief and
> ~/library/django-ils/bookshare, where really you would want (i assume)
> ~/library/kochief/ and ~/library/bookshare/
>>
> maybe i'll replace the name bookshare in my code with django-ils and then
> not have only a single file at the root of my repo as you suggest (ie, put
> it back the way it was with manage.py in the root of the repo). sorry if
> that doesnt make sense, I'm sure there is proper terminology...
It's a good idea to keep the code as it is, in a directory with the
project name within the repo. You can't control the name of the
directory people will clone the code into, but the project needs to be
in "bookshare" because the project name is in settings.INSTALLED_APPS.
So if you put manage.py, etc. in the root of the repo but I check out
the repo into a directory called "ils-thing" or even "bookshare-dev"
then the code won't run.
In production, the reasons for this become more clear. For Kochief, I
have a single machine with a few instances running, so the directory
structure looks as follows:
/srv/www/inst1/kochief
/srv/www/inst1-dev/kochief
/srv/www/inst2/kochief
/srv/www/inst2-dev/kochief
Each of the dev instances are cloned from the public repo (e.g., "hg
clone https://kochief.googlecode.com/hg/ inst1-dev") while the
production instances are cloned from the dev instances (e.g., "hg
clone file:///srv/www/inst1-dev inst1").
> anyways, thanks. I'm working on other things but when I get around to
> wanting to load marc files from django-ils in kochief I'll bother y'all
> about any errors I get.
The commit I made last night might address some of your character
encoding issues, so pull and update and give that a try.
Looks better. It's great to be able to run "python manage.py syncdb &&
> I have implemented your suggestions
python manage.py runserver" in a freshly-cloned repo and see a working
project. You might still want to add an .hgignore with lines as
follows:
syntax: glob
*.pyc
bookshare/.DdBb
They weren't around, but were created when I ran "python manage.py
syncd". If you add that .hgignore file you created to the repo then I
won't see them when I do "hg st".