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:[email protected]]
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" <[email protected]> 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:[email protected]]
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
[email protected]
http://www.dtu.dk/english
On 11/06/2018, 12.25, "Banerji, Sangeeta" <[email protected]> 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
