Do not build / remove software collections

[marcelzwiers]

BIDScoin is a separate neurocontainer, but it is also contained in bidstools:

## bidstools/1.0.2 ##
Contains a collection of tools useful for DICOM to BIDS conversion

Tools included:
dcm2niix: v1.0.20230411 https://github.com/rordenlab/dcm2niix
bidscoin: https://bidscoin.readthedocs.io
dcmtk: https://support.dcmtk.org/docs/pages.html
xmedcon: https://xmedcon.sourceforge.io/
heudiconv: https://heudiconv.readthedocs.io/en/latest/heuristics.html
Bru2Nii: https://github.com/neurolabusc/Bru2Nii

As far as I know, none of these tools depend on each other, and in my view neurodesk / the user is much better off loading the individual modules than loading a single module with the same collection of outdated (at least that will happen quickly) packages. Is it an option to remove these containers, or at least flag them as NOT MAINTAINED or so?

[marcelzwiers]

Instead of building a container for it, you could also just simply make a software collection module (that loads the individual modules)

[stebo85]

yes, that's a good idea. Will remove bidscoin from this container.

[marcelzwiers]

Ok, but it's not just bidscoin, also the other applications do not depend on each other and are better off in their own container?

…

_____________________ Sent from my phone Op di 20 feb 2024 23:06 schreef Steffen Bollmann ***@***.***>:

Closed #596 <#596> as completed. — Reply to this email directly, view it on GitHub <#596 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADTUGL4NFTCN6Z3DXA6HS23YUUM5JAVCNFSM6AAAAABDQ574KCVHI2DSMVQWIX3LMV45UABCJFZXG5LFIV3GK3TUJZXXI2LGNFRWC5DJN5XDWMJRHA3DOOJVGE2DMMA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[stebo85]

yes, but isn't there also value in packaging tools with common tasks in one container? If every tool is in its own container then an HPC user has to download all of the individual containers for example. It would also clutter the Application menu if every little tool gets it's own entry. Also users don't often know what tools can be used for a certain task - so bundling tools with common tasks would help in discovery?

[marcelzwiers]

I think then you end up somewhere in between neurodebian and neurodesk. Why not build separate containers and, if you want to offer software collections, then create this at the module level? It's much easier to maintain and much more flexible

…

_____________________ Sent from my phone Op di 20 feb 2024 23:13 schreef Steffen Bollmann ***@***.***>:

yes, but isn't there also value in packaging tools with common tasks in one container? If every tool is in its own container then an HPC user has to download all of the individual containers for example. It would also clutter the Application menu if every little tool gets it's own entry. Also users don't often know what tools can be used for a certain task - so bundling tools with common tasks would help in discovery? — Reply to this email directly, view it on GitHub <#596 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADTUGL6SG4PBZSEMNMMYASDYUUNZFAVCNFSM6AAAAABDQ574KCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJVGIYDONJYGA> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[stebo85]

Yes, bundling individual tools on the module level would be a great solution, but currently, our module generation scripts do not support this yet. We also want to move the application menu system to use the module system, but this is not yet completed: NeuroDesk/neurocommand#152, this is also connected to the SHPC rewrite: NeuroDesk/transparent-singularity#7 - we are currently trying to get resources to work on this, but until we have this completed, bundling tools in one container is our best option.

[marcelzwiers]

Ok, I see. Does this mean that you can only load one module at the same time in neurodesk? Op di 20 feb 2024 om 23:27 schreef Steffen Bollmann < ***@***.***>:

…

Yes, bundling individual tools on the module level would be a great solution, but currently, our module generation scripts do not support this yet. We also want to move the application menu system to use the module system, but this is not yet completed: NeuroDesk/neurocommand#152 <NeuroDesk/neurocommand#152>, this is also connected to the SHPC rewrite: NeuroDesk/transparent-singularity#7 <NeuroDesk/transparent-singularity#7> - we are currently trying to get resources to work on this, but until we have this completed, bundling tools in one container is our best option. — Reply to this email directly, view it on GitHub <#596 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADTUGL4BCHV6ZTBBLKVKUALYUUPO3AVCNFSM6AAAAABDQ574KCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJVGIZDINZTGI> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[stebo85]

No, you can already load multiple modules in Neurodesk at the same time. What's not yet possible right now is to create a meta-module that loads multiple other modules automatically. So to implement your suggestion, we would need a meta-module called "bidstools" that would then load individual containers like bru2nii, bidscoin, dcm2niix ... this then also needs to be integrated into the Application menu to avoid cluttering the menu with lot's of little tools. It's definitely something we want to do, but we currently lack the resources to implement this