Adopt sickle wrapper?

[nsoranzo]

There are presently 2 sickle wrappers on the Main Tool Shed:

• https://toolshed.g2.bx.psu.edu/view/nikhil-joshi/sickle/ (from @najoshi, the author of sickle)
• https://toolshed.g2.bx.psu.edu/view/nilesh/sickle/ (originally from @nkav, last updated in 2015 by our @yhoogstrate)

I've tried to update the first one with najoshi/sickle#44, but got no answer. So I was thinking it may make sense to import the wrapper code in this repo, update it and then push to nilesh repository if @yhoogstrate or @nkav can grant authority to iuc on the Main and Test Tool Sheds.

Opinions?

[bgruening]

@nsoranzo in general I like the idea of merging wrappers and converging to one high quality wrapper.
Two points to consider/discuss:

1. Do we want to minimize the functional overlap of our tools? In other words, again a new trimmer? Do we need it?
2. Currently, non-iuc repositories can have some disadvantages.

• No one knows which one of the above three is the preferred IUC one (star'ring of repositories does not work yet).
• Write permission can be revoked or any other harm can happen which we can not control (repository redirections are missing)

Maybe, I'm just too pessimistic but we should be aware of this and under some circumstances it might be better to create a IUC repository for such tools. That said, as soon as we have proper star'ing and redirection of repositories these problems are obsolete.

Opinions?

[yhoogstrate]

Given the number of downloads of these packages and that there are already 3 wrappers around I think it's beneficial to update one of these existing wrappers (preferable the one with the highest number of downloads).

I am not sure whether it's more appropriate to use your personal or the iuc account for this. To me it's a bit confusing to find IUC maintained tools under the names of others, and as Bjoern says revoking access may happen. On the other hand, it happened before (#339) and maintenance by IUC is good for careful reviews and bug reporting.

Opinions?

I'm also curious. Maybe @erasche has any suggestions from the Jenkins perspective?

[nsoranzo]

@bgruening

1. Do we want to minimize the functional overlap of our tools? In other words, again a new trimmer? Do we need it?

sickle seems to be the best sliding-window trimmer, and I have users for it here.

No one knows which one of the above three is the preferred IUC one (star'ring of repositories does not work yet).

I don't have a solution for this, but I guess people will probably install the one which has been updated more recently/frequently, and we are good at this :)

Write permission can be revoked or any other harm can happen which we can not control

I don't think this is going to happen, and if it happens we just create a repo under iuc.

The only real drawback I see is that only the original owner can update the repository metadata (Tool Shed bug? @martenson).

[martenson]

@nsoranzo Where did you see this? I thought we solved this along with the security bug found by Peter.

[nsoranzo]

@martenson If I login as iuc on the MTS user interface, I cannot change the description/categories/... of crs4's taxonomy_krona_chart.

[hexylena]

@yhoogstrate given some of the issues we've had when we don't have ultimate control over the repo, I'm very much in favour of anything with the "IUC" name on it. So many problems to be avoided w/r/t jenkins & friends.

[martenson]

@nsoranzo iuc seems to have write permissions, did you try doing it through api/planemo?

[nsoranzo]

@martenson: no, web UI.

[nsoranzo]

• Since nobody objected, I'll open a PR for sickle;
• There is no consensus on which repo to use and we got no offer from the 2 repo owners, so I'll use owner iuc
• For the Tool Shed bug, I've opened Tool Shed: user with write permissions cannot change repo metadata through UI galaxy#1021 .