SIP still uses package source when running under gitified

[mrenvoize]

Currently, it's rather challenging to test code that changes the SIP services under a gitified environment.

When the koha-sip script is envoked, it works with code in /usr/lib/koha instead of the gitified code.

[chrisosaurus]

I don't think this should be fixed from the koha-gitify end, doing so would be a very far reaching and hard to maintain change, koha-gitify aims to be minimally invasive (avoiding breaking non-gitified instances is very important).

The ideal fix would be for this to be fixed on the koha side.
Currently most of the debian scripts have hardcoded paths (look inside debian/scripts/koha-start-sip for an example).
Ideally we should be running all commands via koha-shell and rely on koha-shell to correctly set up the environment (most likely sourcing the perl5lib from an instance dependent location inside /etc/koha).

I had plans to either modify koha-script or introduce a new koha-env script to do such things.

The problem with this approach is it would also affect non-gitified koha instances, and for little gain to them.

[chrisosaurus]

For now I am marking this as wontfix as I don't think it is feasible from the koha-gitify end of things.

[wizzyrea]

What I did on the gitified dev install is simply change the environment path in the koha-start-sip script. Yes, it affects all of the instances, but since it was a test box it didn't much matter.

[chrisosaurus]

@wizzyrea yeah that is an easy fix

but for the general case (of wanting to mix gitified and non-gitified) we would most likely need an upstream change for the various cron jobs to obey some path setting (so we could set it per instance)

this general case would also work if we wanted many gitified instances but each with a different path.

[wizzyrea]

Yeah, I was just noting it down for anyone else who needed/wanted a workaround :)

[chrisosaurus]

@wizzyrea +1

[mrenvoize]

I never got back to this one.. sorry.

I'm using gitified less and less to be honest. I think we're a fringe case, but we come up against allot of these issues pretty often. It's still a great tool, and it's great to see people using it so much.. but for my dev and qa tasks I'll be sticking to full dev type installs for a while yet.