A new request with request id 17466 has been created by koha-devel-request@lists.koha-community.org. Short info on the request is :

Title : Koha-devel Digest, Vol 187, Issue 12
Category :
Description :
Send Koha-devel mailing list submissions to
    koha-devel@lists.koha-community.org

To subscribe or unsubscribe via the World Wide Web, visit
    https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
or, via email, send a message with subject or body 'help' to
    koha-devel-request@lists.koha-community.org

You can reach the person managing the list at
    koha-devel-owner@lists.koha-community.org

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Koha-devel digest..."


Today's Topics:

1. Re: some thoughts on #28519 regarding lib
(dcook@prosentient.com.au)
2. Re: some thoughts on #28519 regarding lib
(dcook@prosentient.com.au)


----------------------------------------------------------------------

Message: 1
Date: Wed, 16 Jun 2021 13:42:08 +1000
From: <dcook@prosentient.com.au>
To: "'Jonathan Druart'" <jonathan.druart@bugs.koha-community.org>,
    "'koha-devel'" <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib
Message-ID: <01df01d76261$955eb280$c01c1780$@prosentient.com.au>
Content-Type: text/plain;    charset="utf-8"

Ditto what Jonathan said. CGI::Session::Serializer::yamlxs is 100% a Koha module at this point. Doesn't exist on CPAN.

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.

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Jonathan Druart
Sent: Tuesday, 15 June 2021 7:26 PM
To: koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib

Hi Thomas,

I've sent the following notes to the QA team, but maybe it needed to be public.
The history behind 28519 is not trivial :)

"""
To clarify and explain a bit more what we are doing here (to those outside of the loop):
- We switched from YAML[::Syck] to YAML::XS (22824, 27673)
- We had to replace the YAML serializer provided by CGI::Session (no YAML::XS serializer exists in cpan).
- 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).
- 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
confusion: the bug appears only if strict_sql_modes is on.
- We need a fix for 21.05.01!
- There are several options we investigate on Friday, lot seems to be working but few really work:
* $Data::Dumper::Useperl=1 (maybe)
* Reintroduce YAML::Syck and get back to CGI::Session::Serializer::YAML
* 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.

What's next?
- We need 28489 for 21.05.01
- Ideally we need 28519 as well!
- We should move to Data::Session and decide on the JSON serializer or write our YAML::XS serializer for Data::Session (17427) """

We actually need CGI::Session::Serializer::yamlxs, not CGI::Session (we are still installing it from the debian package).

Hope that clarifies
Cheers,
Jonathan

Le mar. 15 juin 2021 à 10:48, Thomas Klausner <domm@plix.at> a écrit :
>
> Hi!
>
> without knowing a lot of Koha-internals (still..), I'd strongly prefer
> to have all the code in a lib dir (as is standard in Perl apps /
> modules for ages).
>
> There are also a lot of tools available to make using code stored
> `lib` (but not "installed" in the system, i.e. only available in the
> checkout) easy. The simplest is of course 'lib':
> https://perldoc.perl.org/lib
>
> Or more complex like https://metacpan.org/pod/lib::projectroot (which
> I wrote some time ago to handle a Monorepo setup; it also includes a
> comparison of different modules in the SEE ALSO section)
>
> OTOH, CGI::Session::Serialize is a cpan module, so technically it
> should not be checked out into the app code `lib`, but installed as a
> dependency. There are even more ways to handle installing of
> dependencies and the finding them, but the currently most comfortable
> one is https://metacpan.org/pod/Carton. Or (if running everything via
> Carton is too much of a change), a combination of
> https://metacpan.org/pod/local::lib and a modern CPAN client
> (https://metacpan.org/pod/App::cpanminus or
> https://metacpan.org/pod/App::cpm.
>
> I did not want to spam the actuall ticket with this, as I'm not sure
> if any of this is in fact relevant to the bug, and/or matches the
> current plans for Koha.
>
> Greetings,
> domm
>
>
> --
> #!/usr/bin/perl https://domm.plix.at
> for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/ git :
> https://git.koha-community.org/ bugs :
> https://bugs.koha-community.org/
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/




------------------------------

Message: 2
Date: Wed, 16 Jun 2021 14:58:36 +1000
From: <dcook@prosentient.com.au>
To: "'Jonathan Druart'" <jonathan.druart@bugs.koha-community.org>,
    "'koha-devel'" <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib
Message-ID: <01ea01d7626c$43b9f790$cb2de6b0$@prosentient.com.au>
Content-Type: text/plain;    charset="utf-8"

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.

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.

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.

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of dcook@prosentient.com.au
Sent: Wednesday, 16 June 2021 1:42 PM
To: 'Jonathan Druart' <jonathan.druart@bugs.koha-community.org>; 'koha-devel' <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib

Ditto what Jonathan said. CGI::Session::Serializer::yamlxs is 100% a Koha module at this point. Doesn't exist on CPAN.

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.

David Cook
Software Engineer
Prosentient Systems
Suite 7.03
6a Glen St
Milsons Point NSW 2061
Australia

Office: 02 9212 0899
Online: 02 8005 0595

-----Original Message-----
From: Koha-devel <koha-devel-bounces@lists.koha-community.org> On Behalf Of Jonathan Druart
Sent: Tuesday, 15 June 2021 7:26 PM
To: koha-devel <koha-devel@lists.koha-community.org>
Subject: Re: [Koha-devel] some thoughts on #28519 regarding lib

Hi Thomas,

I've sent the following notes to the QA team, but maybe it needed to be public.
The history behind 28519 is not trivial :)

"""
To clarify and explain a bit more what we are doing here (to those outside of the loop):
- We switched from YAML[::Syck] to YAML::XS (22824, 27673)
- We had to replace the YAML serializer provided by CGI::Session (no YAML::XS serializer exists in cpan).
- 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).
- 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
confusion: the bug appears only if strict_sql_modes is on.
- We need a fix for 21.05.01!
- There are several options we investigate on Friday, lot seems to be working but few really work:
* $Data::Dumper::Useperl=1 (maybe)
* Reintroduce YAML::Syck and get back to CGI::Session::Serializer::YAML
* 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.

What's next?
- We need 28489 for 21.05.01
- Ideally we need 28519 as well!
- We should move to Data::Session and decide on the JSON serializer or write our YAML::XS serializer for Data::Session (17427) """

We actually need CGI::Session::Serializer::yamlxs, not CGI::Session (we are still installing it from the debian package).

Hope that clarifies
Cheers,
Jonathan

Le mar. 15 juin 2021 à 10:48, Thomas Klausner <domm@plix.at> a écrit :
>
> Hi!
>
> without knowing a lot of Koha-internals (still..), I'd strongly prefer
> to have all the code in a lib dir (as is standard in Perl apps /
> modules for ages).
>
> There are also a lot of tools available to make using code stored
> `lib` (but not "installed" in the system, i.e. only available in the
> checkout) easy. The simplest is of course 'lib':
> https://perldoc.perl.org/lib
>
> Or more complex like https://metacpan.org/pod/lib::projectroot (which
> I wrote some time ago to handle a Monorepo setup; it also includes a
> comparison of different modules in the SEE ALSO section)
>
> OTOH, CGI::Session::Serialize is a cpan module, so technically it
> should not be checked out into the app code `lib`, but installed as a
> dependency. There are even more ways to handle installing of
> dependencies and the finding them, but the currently most comfortable
> one is https://metacpan.org/pod/Carton. Or (if running everything via
> Carton is too much of a change), a combination of
> https://metacpan.org/pod/local::lib and a modern CPAN client
> (https://metacpan.org/pod/App::cpanminus or
> https://metacpan.org/pod/App::cpm.
>
> I did not want to spam the actuall ticket with this, as I'm not sure
> if any of this is in fact relevant to the bug, and/or matches the
> current plans for Koha.
>
> Greetings,
> domm
>
>
> --
> #!/usr/bin/perl https://domm.plix.at
> for(ref bless{},just'another'perl'hacker){s-:+-$"-g&&print$_.$/}
> _______________________________________________
> Koha-devel mailing list
> Koha-devel@lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : https://www.koha-community.org/ git :
> https://git.koha-community.org/ bugs :
> https://bugs.koha-community.org/
_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/


_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/ git : https://git.koha-community.org/ bugs : https://bugs.koha-community.org/




------------------------------

Subject: Digest Footer

_______________________________________________
Koha-devel mailing list
Koha-devel@lists.koha-community.org
https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
website : https://www.koha-community.org/
git : https://git.koha-community.org/
bugs : https://bugs.koha-community.org/


------------------------------

End of Koha-devel Digest, Vol 187, Issue 12
*******************************************


NOTE: You are receiving this mail because, the Requester/Technician wanted you to get notified on this request creation.