Hi, On 12/17/07, MJ Ray <[EMAIL PROTECTED]> wrote: > "Galen Charlton" <[EMAIL PROTECTED]> wrote: > > On 12/14/07, MJ Ray <[EMAIL PROTECTED]> wrote: > > > "Galen Charlton" <[EMAIL PROTECTED]> wrote: > > > > On 12/13/07, MJ Ray <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED] p: 1-888-564-2457 x709 _______________________________________________ Koha-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/koha-devel
