AW: Question regarding ResFinder
Dear Rolf,
thanks a lot for the clarification. I've adapted the preliminary Debian packaging to this tag.
Unfortunately I have some further issues:
1. There is some missing Perl module:
$ resfinder.pl
Can't locate Try/Tiny/Retry.pm in @INC (you may need to install the Try::Tiny::Retry module) (@INC contains: /etc/perl /usr/local/lib/x86_64-linux-gnu/perl/5.26.2 /usr/local/share/perl/5.26.2 /usr/lib/x86_64-linux-gnu/perl5/5.26 /usr/share/perl5 /usr/lib/x86_64-linux-gnu/perl/5.26 /usr/share/perl/5.26 /usr/local/lib/site_perl /usr/lib/x86_64-linux-gnu/perl-base) at /usr/bin/resfinder.pl line 9.
BEGIN failed--compilation aborted at /usr/bin/resfinder.pl line 9.
There exists some Debian packaged Retry.pm:
libfile-flock-retry-perl: /usr/share/perl5/File/Flock/Retry.pm
No idea whether this will work as well. Or do we need this one
https://metacpan.org/pod/Try::Tiny::Retry ?
2. You will probably not like to change the file name
but there is some good advise to not add the programming
language of some program to the file name.
https://wiki.debian.org/UpstreamGuide#Language_extensions_in_scripts
One of the reasons given there is very true for your current
situation where the code is rewritten - at some point in time
there will be resfinder.py and your users need to learn some new
name while they most probably do not care at all about programming
languages. I'd recommend to at least not use the *.py extension
in future versions.
3. In INSTALL_DB you hard code non-annonymous cloning from a git
repository. I've added a patch
https://salsa.debian.org/med-team/resfinder/blob/master/debian/patches/anonymous_cloning_db.patch
to enable any user cloning the database.
Kind regards
Andreas.
-----Ursprüngliche Nachricht-----
Von: Rolf Sommer Kaas [mailto:rkmo@food.dtu.dk]
Gesendet: Dienstag, 19. Juni 2018 11:36
An: Tille, Andreas; Banerji, Sangeeta
Betreff: Re: Question regarding ResFinder
Dear Andreas,
I finally got around to look into this. It was a little complicated, as the version number didn’t match what I expected, and I have not been responsible for previous versions of ResFinder, so I had to make sure which version was currently on the master branch. It turned out that the version number in the code was incorrect. It is actually version 2.3 that is on the master branch. I’ve corrected the code and created the appropriate tag.
When we release version 4, we will have done a lot of cleaning up and the releases, branches and so on will hopefully be following the standards of GitFlow.
Best,
Rolf
On 15/06/2018, 08.26, "Tille, Andreas" <TilleA@rki.de> wrote:
Dear Rolf,
thanks for the clarification. From the line
use constant VERSION => '2.1';
in file resfinder.pl I assumed that the Perl version of ResFinder is version 2.1 and from your mail that is the stable version. Could you please enable downloading a tar.gz archive of this stable version. While I'm perfectly able to clone the Git repository it is not fully clear whether "random" Git commits that might go beyond a version 2.1 "release" are just development code that is leading to a possible new release 2.2 of the Perl code or whether users are supposed to install the latest Git commit. As Sangeeta wrote my intention is to package all software we are using for official Debian and there we have tools checking for new version according to downloadable tarballs. The release of a tarball is a signal what software developers want users to be installed on their machines.
Unfortunately I have no idea how the tarball creation works on bitbucket. On Gitlab and Github it is just by creating a release tag. I assume it will be equally simple on bitbucket (a quick search uncovered https://confluence.atlassian.com/bitbucket/use-repository-tags-321860179.html which seems to support my assumption).
Kind regards and thanks for your cooperation
Andreas.
-----Ursprüngliche Nachricht-----
Von: Rolf Sommer Kaas [mailto:rkmo@food.dtu.dk]
Gesendet: Montag, 11. Juni 2018 23:20
An: Banerji, Sangeeta
Cc: Tille, Andreas
Betreff: Re: Question regarding ResFinder
Dear Sangeeta and Andreas,
The branch 4.0 is the development branch for ResFinder 4.0 and is not published, and not ready to run outside DTU.
The master branch is the current published/stable version.
We are working very hard on getting 4.0 published as it is a complete reimplementation of ResFinder and it adds a mapping based solution along with a completely new database, that attempts to translate genotypes to phenotypes. If you wish to receive an email when we are ready to beta test 4.0, I’ll be happy to put you on the list?
Best regards,
Rolf Sommer Kaas
Researcher
Research Group for Genomic Epidemiology
National Food Institute
------------------------------------
Technical University of Denmark
Søltofts Plads
Building 221, Room 054
2800 Kgs. Lyngby
Direct +45 35886333
rkmo@food.dtu.dk
http://www.dtu.dk/english
On 11/06/2018, 12.25, "Banerji, Sangeeta" <BanerjiS@rki.de> wrote:
Dear Rolf,
I have a question regarding ResFinder and I hope you can answer it. I asked our linux guy (Andreas Tille) to package ResFinder for Debian. However, he wonders why there are two different codes available. A perl code and a python code: https://bitbucket.org/genomicepidemiology/resfinder.git and https://bitbucket.org/genomicepidemiology/resfinder/downloads/?tab=branches
Are both codes updated and equal or should we prefer one of them for Debian packaging? Also, Andreas could not find a copy of the Apache license with the code. I see that you have a link to Apache 2.0 license on the ResFinder bitbucket site but maybe you should also distribute it with the code.
All the best,
Sangeeta
Reply to: