Hi, On 12/17/07, MJ Ray <mjr@phonecoop.coop> wrote:
"Galen Charlton" <galen.charlton@liblime.com> wrote:
On 12/14/07, MJ Ray <mjr@phonecoop.coop> wrote:
"Galen Charlton" <galen.charlton@liblime.com> wrote:
On 12/13/07, MJ Ray <mjr@phonecoop.coop> wrote: again. Can we add the supplied default value to the valid values, just to be sure?
Yep.
OK, so will you commit something like this, or shall I?
I committed a change on 14 December for this. [snippage re C4]
Maybe not absent the rest of Koha, but other scripts (think contrib) may want to use them later and it would be cleaner if they don't have to be installed into koha or with koha-specific details that they don't need otherwise. I think C4 is more than simply organising Koha's code - it defines the API used by other developers.
C4 is an API which is generally non-functional if not connected to a Koha database. Sorry, I find it rather unlikely that any Koha contribs that involve Perl code (outside of a consumer of one of the web services) will be developed or deployed outside of a full Koha installation.
There are several Debian packages for Perl web applications that follow what I'm suggesting and put the application-specific modules under /usr/share/<package>/lib, including request-tracker3.6 (i.e., RT) and cgiirc. While not all Perl web-apps do this, there is enough of a precedent.
I'll be disappointed if packaged koha is as much hassle to install and get running as RT. (We're keen RT users, but the debian package doesn't make life much simpler IME.)
Once a package is created that includes all of the dependencies, I do not see why there should be any particular issue. The only things that would require manual setup would be presumably (a) creating the mysql database, since I assume a Debian package installer wouldn't do this automatically as a matter of policy. (b) starting Zebra and zebraqueue_daemon (or the cronjob) (c) tuning the Apache configuration, assuming that Koha is not necessarily the only web app installed.
[C4-finding scripts]
The upshot is that now, after doing an installation, no environment variables need to be set to use the command-line tools.
Great. Why should they still have to be set in Apache on single-Koha hosts?
Considering that the supplied koha-httpd.conf already does this, I do not see what the issue is.
I don't recall why kohaversion.pl was added in August when $C4::Context::VERSION was already there. Are we stuck with it? Can we replace it with use C4::Context; return $C4::Context::VERSION? I don't know the history, but I do like having some kind of separation, mostly for the trivial reason that the log for C4/Context.pm wouldn't get cluttered with commits that are not really related to Context.pm itself.
So someone make C4::Version if they fancy it. It seemed cleaner to me for C4::Context (which is loaded by everything, to get the configuration) to host it.
Yes, I agree that this is the way to go.
No, we can still apply the version check to C4::Context by overriding the VERSION method -- we would need to do this anyway, as the VERSION imported from UNIVERSAL.pm croaks only if the requested version is larger than the module's $VERSION. [...]
How? Are you suggesting the C4::Context module will invoke the kohaversion.pl script? So script loads module loads script? If so, this really seems a strange way to do it.
That is in fact the current behavior. However, I thus far have not found any reason why this is preferable to having a C4::Version module, so I'm inclined to change this.
Why would we need to override the VERSION method? I thought the idea was to use only.pm.
I'm experimenting with both approaches. Regards, Galen -- Galen Charlton Koha Application Developer LibLime galen.charlton@liblime.com p: 1-888-564-2457 x709