Skip to content

Alternative minification encoding #2684

@Lestropie

Description

@Lestropie

In discussing the utility of the NeuroDocker minification process for another project, a prospective alternative utilisation came to mind.

Currently, what happens for a given external dependency (eg. FSL) is:

  1. A container is built that contains the full installation of that software.
  2. A set of exemplar MRtrix3 scripts is executed to determine which features of that external software may be utilised.
  3. The features of that software not utilised are deleted from the container.
  4. The remaining features are tarballed and uploaded online.
  5. When building the MRtrix3 image, that tarball is downloaded.

What I dislike about this strategy is that we are very explicitly providing parallel downloads of other peoples' softwares.

What we could do instead is:

  1. Generate and store in the main repository a text file that encodes which files need to be retained / removed from the installation of that software.
  2. When building the MRtrix3 image, retain / remove the relevant files.

This means that if anyone is logging download counts of their software at their end, image build triggers will still count toward that total.

(Note this isn't the only change I want to make w.r.t. containers, but it might be a contribution in the right direction)

Metadata

Metadata

Assignees

Labels

containerDocker or Singularity containers

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions