You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
new AMRfinderplus user - very useful tool, thanks!
I may be missing something, but it appears that the only way to automatically download/build the database is through the amrfinder_update executable. The way I read the code is that it will always download the "latest" release of the database. While this is mostly fine, it does not conform well with the concept of versioning workflows - i.e. I can guarantee that all the data processing up to the AMRfinderplus stage is always identical, but the database may differ depending on when the user installed the workflow. This is not a very good situation imho.
Any chance that the database installation function could be changed to accept specific release tags or similar?
( I guess a workaround may be to just download the un-indexed database files "manually" and figure out the indexing commands, but it would be nice to have that be part of the default installation procedure).
Cheers
Marc
The text was updated successfully, but these errors were encountered:
To add to what Slava said above, you can download the database files from our FTP site and run amrfinder_index <database_dir> to (re)index the database you downloaded (see also the documentation).
Thanks, I will look into the download and re-indexing option.
My workflow uses bioconda and biocontainers (depending on the user preference), so the version of Amrfinder is basically "locked". The next step would be to also lock the database version so everything is fully version-controlled.
Hi,
new AMRfinderplus user - very useful tool, thanks!
I may be missing something, but it appears that the only way to automatically download/build the database is through the amrfinder_update executable. The way I read the code is that it will always download the "latest" release of the database. While this is mostly fine, it does not conform well with the concept of versioning workflows - i.e. I can guarantee that all the data processing up to the AMRfinderplus stage is always identical, but the database may differ depending on when the user installed the workflow. This is not a very good situation imho.
Any chance that the database installation function could be changed to accept specific release tags or similar?
( I guess a workaround may be to just download the un-indexed database files "manually" and figure out the indexing commands, but it would be nice to have that be part of the default installation procedure).
Cheers
Marc
The text was updated successfully, but these errors were encountered: