search

galaxy-iuc / standards

Documentation for standards and best practices from the Galaxy IUC
http://galaxy-iuc-standards.readthedocs.io/en/latest/
6 stars 16 forks source link

Categories for "packages". #9

Closed jmchilton closed 7 years ago

jmchilton commented 9 years ago

I would say package_ (e.g. tool_dependeny_definition) repositories should be placed only the Tool Dependency Definitions category and no other categories (to minimize user confusion). I had this on my shed linting TODO list - and tried it out and found some violations in IUC which made me think there should be discussion before I "enforce" it as a best practice.

bgruening commented 9 years ago

:+1:

nsoranzo commented 9 years ago

:+1

peterjc commented 9 years ago

It seems wrong to me to have repository types and categories conflated as they are, so this ought to be sorted out one way or another - and this proposal seems like a reasonable way forward.

Another idea is make Tool Dependency Definitions a virtual category (applied within the Tool Shed itself as the sole category of a tool_dependeny_definition type repository, which have no categories of their own defined in .shed.yml).

However, I think that the Tool Dependency Definitions category should be removed, and we use the (real) categories on all kinds of Tool Shed repositories equally. If we want to make it easier to find package/dependency packages on the tool shed, maybe we need changes to the Tool Shed instead?

(However, I am apparently in a minority, and don't feel that strongly about this - so will readily yield to the IUC consensus here.)

hexylena commented 9 years ago

However, I think that the Tool Dependency Definitions category should be removed, and we use the (real) categories on all kinds of Tool Shed repositories equally.

I'm a fan of this approach. Always seemed weird to separate them and have a single category with thousands of packages.

However, likewise, I don't feel too strongly (and if we switch to brew, some packages will surely go away) about this and am willing to yield as well. So many people are already using the existing convention, it's probably easier to just lint on it like @jmchilton is recommending. Reluctant :+1:

nsoranzo commented 7 years ago

Maybe we can close this? New packages shouldn't be needed any more.

bgruening commented 7 years ago

Yes, let's close this. Conda!!!