[Koha-devel] Adopting CPAN and Carton

Tue Jun 9 15:42:28 CEST 2020

On Tue, Jun 9, 2020 at 2:47 AM Julian Maurice <julian.maurice at biblibre.com>
wrote:

> I'm all for installing Perl modules directly from CPAN. I'm less sure
> about Carton. Is it really needed ? I believe that `cpanm --installdeps
> .` does the same thing.
>
>
Carton would, in theory, speed up the installation because Koha would have
a snapshot of all the Perl deps we need. I've had fairly good results with
Carton, I'm all for using it, but it should definitely be optional. If
somebody wants to install Koha on a platform that we haven't packaged the
libraries for, cpanm --installdeps should work.

> Anyway, I think the first step would be to write documentation on how to
> use this installation method. Even if not adopted, it can't hurt anyone
> to have an alternate method documented.
> Can you write it ?
>
> Le 09/06/2020 à 01:13, dcook at prosentient.com.au a écrit :
> > It would mean that the Koha community would support "CPAN and Carton" as
> an installation method or use it as *the* installation method for Koha.
> >
> > David Cook
> > Systems Librarian
> > Prosentient Systems
> > 72/330 Wattle St
> > Ultimo, NSW 2007
> > Australia
> >
> > Office: 02 9212 0899
> > Online: 02 8005 0595
> >
> > -----Original Message-----
> > From: Koha-devel <koha-devel-bounces at lists.koha-community.org> On
> Behalf Of Julian Maurice
> > Sent: Friday, 5 June 2020 5:12 PM
> > To: koha-devel at lists.koha-community.org
> > Subject: Re: [Koha-devel] Adopting CPAN and Carton
> >
> > Hi,
> >
> > As you said it is already feasible and very easy to do. So what would it
> mean to "adopt CPAN and Carton" ?
> >
> > Le 05/06/2020 à 08:10, dcook at prosentient.com.au a écrit :
> >> Now that I think about it, embedding the Perl modules in the Debian
> >> package could be problematic due to dependencies on C libraries.
> >> (Currently building Text::Bidi on an OpenSUSE system and it's taking
> >> forever.)
> >>
> >> I actually found it pretty challenging to read replies interweaved in
> >> emails, so I might not respond to all that.
> >>
> >> But yeah I could see the most likely option being keeping the Debian
> >> packages the way they are and just having an alternative Carton style.
> >> All that is needed for it really is changing the PERL5LIB
> >> environmental variable, so it would be easy enough to do.
> >>
> >> David Cook
> >> Systems Librarian
> >> Prosentient Systems
> >> 72/330 Wattle St
> >> Ultimo, NSW 2007
> >> Australia
> >>
> >> Office: 02 9212 0899
> >> Online: 02 8005 0595
> >>
> >> -----Original Message-----
> >> From: Victor Grousset/tuxayo <victor at tuxayo.net>
> >> Sent: Friday, 5 June 2020 3:15 PM
> >> To: dcook at prosentient.com.au; 'Koha Devel'
> >> <koha-devel at lists.koha-community.org>
> >> Subject: Re: Adopting CPAN and Carton
> >>
> >> Hi o/
> >>
> >> On 20-06-05 02:18, dcook at prosentient.com.au wrote:
> >>> What are people’s thoughts on CPAN and Carton (the Perl version of
> >>> Bundler, Composer, NPM, etc)?
> >>
> >> I hope that something like that would be on our reach. And that it
> >> will make the majority of the work done to support other Linux
> >> distributions, which would be amazing!
> >>
> >>> I like the idea as a way of more easily managing Perl dependencies
> >>> regardless of Linux distribution and version; in other words, we
> >>> could provide the same dependencies regardless of being on Debian
> >>> Jessie/Debian Stretch/Debian Buster or Ubuntu or Fedora or RHEL or
> >> OpenSUSE.
> >>>
> >>>
> >>>
> >>> I suppose the difficulty is how we do a community-friendly deployment?
> >>> I see two main options:
> >>>
> >>>    1. Have the Debian package run “carton install” automatically during
> >>>       install/upgrade
> >>>        1. This could be error prone and difficult to support…  2. Have
> >>> the Koha Debian Package Manager run “carton install” when
> >>>       building the package, and embed the Perl modules in the Koha
> package
> >>>        1. It’s unknown how much this would increase the size of the
> Koha
> >>>           package
> >>
> >> Interesting, I hope such an unified way will be possible.
> >> If not, is the following a valid option?
> >> The current way of managing the perl dependencies for Debian doesn't
> change.
> >> And a carton way of managing the perl dependencies will coexist. (does
> >> it mean just maintaining the cpanfile? I guess I'm very very wrong
> >> here) And packages for the other distros will use carton.
> >>
> >> It would depend of which is more work:
> >> Integrating and maintaining the use of carton in the Debian packages
> >> Or Maintaining the "full" Debian packages in parallel.
> >>
> >> And also how much is valued the fact that for Debian, the perl deps
> >> comes from the repo? (we could keep the versions in sync with Debian,
> >> see [1]) Subparts of this:
> >> - value of Debian patches
> >> - anything else???
> >>
> >>
> >>> I think retaining Debian packages is important, because we have a
> >>> number of non-Perl dependencies, and the Debian packages provide a
> >>> lot of very useful automation.
> >>
> >> Thank for addressing the question of "If we can use Carton, why have
> >> packages at all?"
> >> I trust you and the others for that ^^" I have no idea of whether or
> >> not packages are the best option compared to others. Does anyone have
> >> feedback about the handling of applications with a lot of deps in
> >> other languages than Perl? (that have something similar to Carton)
> >>
> >>
> >>
> >>> Personally, I’m moving away from packaging Perl dependencies as
> >>> Debian packages for non-Koha projects, because it makes porting the
> >>> projects to a newer version of the same OS much more difficult.
> >>
> >>> I know using Debian’s Perl packages have a lot of advantages, as
> >>> they’re tested, reviewed, and patched, but I think it might be time
> >>> to consider a change.
> >>
> >> [1]The cpanfile could still evolve in sync with the Debian package
> >> versions of the perl libs.
> >> That doesn't address the point "patched" => are there a lot of patched
> >> perl packages in Debian?
> >> i.e. enough so that even getting the same versions (as the one in
> >> Debian stable or oldstable) from CPAN will lead to issues compared to
> >> getting them from the Debian packages?
> >>
> >>
> >>
> >> Unrelated idea: if we end up not using the Debian perl packages and
> >> not syncing the versions pulled from CPAN with those in Debian, here
> >> is how we could manage perl deps.
> >> We could have a script that would edit the cpanfile to bump the major
> >> version of one package. Or set it to the latest version.
> >> And run the tests. And if the tests are alright, keep the new package
> >> version and try updating the next package.
> >> This way (hopefully) most of the update work of perl deps would be done.
> >> Edge cases will be dealt with manually.
> >>
> >> Even if we don't directly need it, it could be a nice tool to detect
> >> regressions in our upstream deps way before they fall on us!
> >>
> >> Cheers,
> >>
> >> --
> >> Victor Grousset/tuxayo
> >>
> >>
> >> _______________________________________________
> >> Koha-devel mailing list
> >> Koha-devel at lists.koha-community.org
> >> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> >> website : http://www.koha-community.org/ git :
> >> http://git.koha-community.org/ bugs : http://bugs.koha-community.org/
> >>
> >
>
> --
> Julian Maurice
> BibLibre
> _______________________________________________
> Koha-devel mailing list
> Koha-devel at lists.koha-community.org
> https://lists.koha-community.org/cgi-bin/mailman/listinfo/koha-devel
> website : http://www.koha-community.org/
> git : http://git.koha-community.org/
> bugs : http://bugs.koha-community.org/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.koha-community.org/pipermail/koha-devel/attachments/20200609/90db882b/attachment.htm>