<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN"><html><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8"></head><body>A new request with request id 17466 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is : <br><br>Title : Koha-devel Digest, Vol 187, Issue 12<br>Category : <br>Description : <div>Send Koha-devel mailing list submissions to<br>    koha-devel@lists.koha-community.org<br><br>To subscribe or unsubscribe via the World Wide Web, visit<br>    https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>or, via email, send a message with subject or body 'help' to<br>    koha-devel-request@lists.koha-community.org<br><br>You can reach the person managing the list at<br>    koha-devel-owner@lists.koha-community.org<br><br>When replying, please edit your Subject line so it is more specific<br>than "Re: Contents of Koha-devel digest..."<br><br><br>Today's Topics:<br><br>   1. Re: some thoughts on #28519 regarding lib<br>      (dcook@prosentient.com.au)<br>   2. Re: some thoughts on #28519 regarding lib<br>      (dcook@prosentient.com.au)<br><br><br>----------------------------------------------------------------------<br><br>Message: 1<br>Date: Wed, 16 Jun 2021 13:42:08 +1000<br>From: <dcook@prosentient.com.au><br>To: "'Jonathan Druart'" <jonathan.druart@bugs.koha-community.org>,<br>    "'koha-devel'" <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib<br>Message-ID: <01df01d76261$955eb280$c01c1780$@prosentient.com.au><br>Content-Type: text/plain;    charset="utf-8"<br><br>Ditto what Jonathan said. CGI::Session::Serializer::yamlxs is 100% a Koha module at this point. Doesn't exist on CPAN. <br><br>In this case, I created #28519 to make it easier to use additional namespaces beyond C4 and Koha (and historically OpenILS) without having to update Makefile.PL. Of course, I had to update Makefile.PL for #28519, but I was trying to future-proof us a bit, and trying to provide a way for us to hopefully one day transition all the Perl modules into "./lib", so that we could get the benefits you described, Thomas. <br><br>David Cook<br>Software Engineer<br>Prosentient Systems<br>Suite 7.03<br>6a Glen St<br>Milsons Point NSW 2061<br>Australia<br><br>Office: 02 9212 0899<br>Online: 02 8005 0595<br><br>-----Original Message-----<br>From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Jonathan Druart<br>Sent: Tuesday, 15 June 2021 7:26 PM<br>To: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib<br><br>Hi Thomas,<br><br>I've sent the following notes to the QA team, but maybe it needed to be public.<br>The history behind 28519 is not trivial :)<br><br>"""<br>To clarify and explain a bit more what we are doing here (to those outside of the loop):<br>- We switched from YAML[::Syck] to YAML::XS (22824, 27673)<br>- We had to replace the YAML serializer provided by CGI::Session (no YAML::XS serializer exists in cpan).<br>- We decided to switch back to the default serializer (using Data::Dumper), which we used a looong time ago in Koha already, but faced... encoding problems. However we couldn't replicate them and thought we were safe (28317).<br>- 21.05.00 is released and we discover a bug (28489), there is an encoding issue caused by Data::Dumper (and more precisely its C implementation, see bug 28489 comment 13 for more info). To add to the<br>confusion: the bug appears only if strict_sql_modes is on.<br>- We need a fix for 21.05.01!<br>- There are several options we investigate on Friday, lot seems to be working but few really work:<br>  * $Data::Dumper::Useperl=1 (maybe)<br>  * Reintroduce YAML::Syck and get back to CGI::Session::Serializer::YAML<br>  * Use our own YAML::XS serializer (which has been suggested when we moved to Data::Dumper already) We decided to go with the latter and Andrew wrote a patch. A bit hacky as the Serializer::yamlxs code was inside C4::Auth. David wrote a follow-up (28519) to clean it and move the code to a separate file.<br><br>What's next?<br>- We need 28489 for 21.05.01<br>- Ideally we need 28519 as well!<br>- We should move to Data::Session and decide on the JSON serializer or write our YAML::XS serializer for Data::Session (17427) """<br><br>We actually need CGI::Session::Serializer::yamlxs, not CGI::Session (we are still installing it from the debian package).<br><br>Hope that clarifies<br>Cheers,<br>Jonathan<br><br>Le mar. 15 juin 2021 à 10:48, Thomas Klausner <domm@plix.at> a écrit :<br>><br>> Hi!<br>><br>> without knowing a lot of Koha-internals (still..), I'd strongly prefer <br>> to have all the code in a lib dir (as is standard in Perl apps / <br>> modules for ages).<br>><br>> There are also a lot of tools available to make using code stored <br>> `lib` (but not "installed" in the system, i.e. only available in the <br>> checkout) easy. The simplest is of course 'lib': <br>> https://perldoc.perl.org/lib<br>><br>> Or more complex like https://metacpan.org/pod/lib::projectroot (which <br>> I wrote some time ago to handle a Monorepo setup; it also includes a <br>> comparison of different modules in the SEE ALSO section)<br>><br>> OTOH, CGI::Session::Serialize is a cpan module, so technically it <br>> should not be checked out into the app code `lib`, but installed as a <br>> dependency. There are even more ways to handle installing of <br>> dependencies and the finding them, but the currently most comfortable <br>> one is https://metacpan.org/pod/Carton. Or (if running everything via <br>> Carton is too much of a change), a combination of <br>> https://metacpan.org/pod/local::lib and a modern CPAN client <br>> (https://metacpan.org/pod/App::cpanminus or <br>> https://metacpan.org/pod/App::cpm.<br>><br>> I did not want to spam the actuall ticket with this, as I'm not sure <br>> if any of this is in fact relevant to the bug, and/or matches the <br>> current plans for Koha.<br>><br>> Greetings,<br>> domm<br>><br>><br>> --<br>> #!/usr/bin/perl                             https://domm.plix.at<br>> for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}<br>> _______________________________________________<br>> Koha-devel mailing list<br>> Koha-devel@lists.koha-community.org<br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>> website : https://www.koha-community.org/ git : <br>> https://git.koha-community.org/ bugs : <br>> https://bugs.koha-community.org/<br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/<br><br><br><br><br>------------------------------<br><br>Message: 2<br>Date: Wed, 16 Jun 2021 14:58:36 +1000<br>From: <dcook@prosentient.com.au><br>To: "'Jonathan Druart'" <jonathan.druart@bugs.koha-community.org>,<br>    "'koha-devel'" <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib<br>Message-ID: <01ea01d7626c$43b9f790$cb2de6b0$@prosentient.com.au><br>Content-Type: text/plain;    charset="utf-8"<br><br>Speaking of benefits,  I have a different Perl project I support and develop, and it stores all its Perl modules in a "./lib" directory, and I'm able to easily run my app from a git checkout or a package deployment. The only difference is path configuration.<br><br>Also, while I have provided dependencies via RPM packaging historically, in the not too distant future, I'll be moving to using carton for providing the dependencies from CPAN. In that case, I only store cpanfile and cpanfile.snapshot in my git. Then, in my dev environment, I use cpanfile.snapshot to install the dependencies into carton's default "./local/lib/perl5". When I do my RPM packaging, I do a "git archive" to create my source code bundle, I use tar to bundle "./local" into "<appname-deps>.tar.gz", and then I create 1 package from both those tarballs (although I could easily build separate app.rpm and app-deps.rpm packages). Developing, testing, and deploying is so fast and easy. <br><br>Anyway, baby steps for Koha. Even if we never move away from Debian package dependencies, I think the "./lib" directory is invaluable for allowing us to easily work with multiple Perl module namespaces. <br><br>David Cook<br>Software Engineer<br>Prosentient Systems<br>Suite 7.03<br>6a Glen St<br>Milsons Point NSW 2061<br>Australia<br><br>Office: 02 9212 0899<br>Online: 02 8005 0595<br><br>-----Original Message-----<br>From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of dcook@prosentient.com.au<br>Sent: Wednesday, 16 June 2021 1:42 PM<br>To: 'Jonathan Druart' <jonathan.druart@bugs.koha-community.org>; 'koha-devel' <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib<br><br>Ditto what Jonathan said. CGI::Session::Serializer::yamlxs is 100% a Koha module at this point. Doesn't exist on CPAN. <br><br>In this case, I created #28519 to make it easier to use additional namespaces beyond C4 and Koha (and historically OpenILS) without having to update Makefile.PL. Of course, I had to update Makefile.PL for #28519, but I was trying to future-proof us a bit, and trying to provide a way for us to hopefully one day transition all the Perl modules into "./lib", so that we could get the benefits you described, Thomas. <br><br>David Cook<br>Software Engineer<br>Prosentient Systems<br>Suite 7.03<br>6a Glen St<br>Milsons Point NSW 2061<br>Australia<br><br>Office: 02 9212 0899<br>Online: 02 8005 0595<br><br>-----Original Message-----<br>From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Jonathan Druart<br>Sent: Tuesday, 15 June 2021 7:26 PM<br>To: koha-devel <koha-devel@lists.koha-community.org><br>Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib<br><br>Hi Thomas,<br><br>I've sent the following notes to the QA team, but maybe it needed to be public.<br>The history behind 28519 is not trivial :)<br><br>"""<br>To clarify and explain a bit more what we are doing here (to those outside of the loop):<br>- We switched from YAML[::Syck] to YAML::XS (22824, 27673)<br>- We had to replace the YAML serializer provided by CGI::Session (no YAML::XS serializer exists in cpan).<br>- We decided to switch back to the default serializer (using Data::Dumper), which we used a looong time ago in Koha already, but faced... encoding problems. However we couldn't replicate them and thought we were safe (28317).<br>- 21.05.00 is released and we discover a bug (28489), there is an encoding issue caused by Data::Dumper (and more precisely its C implementation, see bug 28489 comment 13 for more info). To add to the<br>confusion: the bug appears only if strict_sql_modes is on.<br>- We need a fix for 21.05.01!<br>- There are several options we investigate on Friday, lot seems to be working but few really work:<br>  * $Data::Dumper::Useperl=1 (maybe)<br>  * Reintroduce YAML::Syck and get back to CGI::Session::Serializer::YAML<br>  * Use our own YAML::XS serializer (which has been suggested when we moved to Data::Dumper already) We decided to go with the latter and Andrew wrote a patch. A bit hacky as the Serializer::yamlxs code was inside C4::Auth. David wrote a follow-up (28519) to clean it and move the code to a separate file.<br><br>What's next?<br>- We need 28489 for 21.05.01<br>- Ideally we need 28519 as well!<br>- We should move to Data::Session and decide on the JSON serializer or write our YAML::XS serializer for Data::Session (17427) """<br><br>We actually need CGI::Session::Serializer::yamlxs, not CGI::Session (we are still installing it from the debian package).<br><br>Hope that clarifies<br>Cheers,<br>Jonathan<br><br>Le mar. 15 juin 2021 à 10:48, Thomas Klausner <domm@plix.at> a écrit :<br>><br>> Hi!<br>><br>> without knowing a lot of Koha-internals (still..), I'd strongly prefer <br>> to have all the code in a lib dir (as is standard in Perl apps / <br>> modules for ages).<br>><br>> There are also a lot of tools available to make using code stored <br>> `lib` (but not "installed" in the system, i.e. only available in the<br>> checkout) easy. The simplest is of course 'lib': <br>> https://perldoc.perl.org/lib<br>><br>> Or more complex like https://metacpan.org/pod/lib::projectroot (which <br>> I wrote some time ago to handle a Monorepo setup; it also includes a <br>> comparison of different modules in the SEE ALSO section)<br>><br>> OTOH, CGI::Session::Serialize is a cpan module, so technically it <br>> should not be checked out into the app code `lib`, but installed as a <br>> dependency. There are even more ways to handle installing of <br>> dependencies and the finding them, but the currently most comfortable <br>> one is https://metacpan.org/pod/Carton. Or (if running everything via <br>> Carton is too much of a change), a combination of <br>> https://metacpan.org/pod/local::lib and a modern CPAN client <br>> (https://metacpan.org/pod/App::cpanminus or <br>> https://metacpan.org/pod/App::cpm.<br>><br>> I did not want to spam the actuall ticket with this, as I'm not sure <br>> if any of this is in fact relevant to the bug, and/or matches the <br>> current plans for Koha.<br>><br>> Greetings,<br>> domm<br>><br>><br>> --<br>> #!/usr/bin/perl                             https://domm.plix.at<br>> for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}<br>> _______________________________________________<br>> Koha-devel mailing list<br>> Koha-devel@lists.koha-community.org<br>> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>> website : https://www.koha-community.org/ git : <br>> https://git.koha-community.org/ bugs : <br>> https://bugs.koha-community.org/<br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/<br><br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/<br><br><br><br><br>------------------------------<br><br>Subject: Digest Footer<br><br>_______________________________________________<br>Koha-devel mailing list<br>Koha-devel@lists.koha-community.org<br>https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel<br>website : https://www.koha-community.org/<br>git : https://git.koha-community.org/<br>bugs : https://bugs.koha-community.org/<br><br><br>------------------------------<br><br>End of Koha-devel Digest, Vol 187, Issue 12<br>*******************************************<br></div><br><br>NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.<br></body></html>