Git handles that perfectly in both ways:
* a patch has been created with a file in /Koha, and is applied later when it's moved to /lib/Koha
* a file is modified in /lib/Koha and backported into branches which have the file in /Koha
Are we ready for this move? Is it something we really want? Who is willing to spend time on working on this (testing mostly)?
We can push it in the next month if there are volunteers.
And, most of all, what are the possible side-effects and changes needed in side-projects?
What is the benefit exactly?
(In reply to Marcel de Rooy from comment #2)
> What is the benefit exactly?
Now that we have it (the lib directory), it makes sense to use if of our lib :)
It follows the standard for perl projects.
Ideally we also would like to tidy the whole root directory and move the intranet controller scripts to a single directory (see bug 9949).
(In reply to Jonathan Druart from comment #3)
> (In reply to Marcel de Rooy from comment #2)
> > What is the benefit exactly?
> Now that we have it (the lib directory), it makes sense to use if of our lib
> It follows the standard for perl projects.
> Ideally we also would like to tidy the whole root directory and move the
> intranet controller scripts to a single directory (see bug 9949).
Haha, yeah thats what I expected :)
Note that I asked David for this lib folder on the other report too..
I'd love to see this.. it would certainly move us towards being a bit more 'normal' in the perl world.. might mean we can start adopting other more widely supported perl solutions for other things too.. not sure what, but there's loads of perl tooling out there that expects to find things in '/lib'
(In reply to Jonathan Druart from comment #0)
> Are we ready for this move? Is it something we really want? Who is willing
> to spend time on working on this (testing mostly)?
What better time than now?
- It will mean we can keep all our Perl modules together in a place where any (new or old) developer could predict to find them
- It will also make it easier to work with multiple namespaces.
- It will provide a smaller target for git/dev installs (rather than having "lib" be the entire source tree)
- It also provides a mechanism for overriding modules. There are cases where you might want to use a library but want to customize the behaviour of a submodule. It doesn't necessarily make sense to fork an entire library, but you can override a single module, since the Koha "lib" directory is sourced earlier in @INC
- It provides a first step to cleaning up the top-level directory
- It provides an opportunity to find little hacks where we load modules based on file system location rather than their presence in @INC.
I can put some time into this. I imagine most issues would be related to C4 and SIP.
Created attachment 122319 [details] [review]
Bug 28589: git mv C4 lib && git mv Koha lib
Created attachment 122320 [details] [review]
Bug 28589: lib dir adjustements
What else would be needed?