Skip to content

Change license to Apache2, add ability to build+publish to PyPi

Paul McCarthy requested to merge mnt/pypi-publish into master

Hi @duncan (also pinging @mwebster), this MR proposes a couple of things:

  • Change the source code license that covers fsl_sub from the FSL license to the Apache 2 license
  • Enhance the Gitlab CI pipeline to include jobs that:
    1. Build source and wheel packages (build-pypi-dist)
    2. Upload those packages to PyPi (deploy-pypi-dist)

The build-pypi-dist job is run in every CI / CD pipeline - this can be useful to catch changes that break the build for some reason (e.g. errors in

The deploy-pypi-dist job is only triggered when a new tag is added to this repository; this job must also be manually invoked, and requires PyPi login credentials to be set as CI / CD variables called TWINE_USERNAME and TWINE_PASSWORD on this repository.

For the time being, fsl_sub will continue to be published to our internal conda channel (via the fsl/conda/fsl_sub recipe repository). But once we have fsl_sub up on PyPi, we can configure publishing to conda-forge.

There is a potential package naming issue that we will need to think about:

  • FSL is installed from two conda channels:
    - conda-forge
  • Conda channel order is important - packages in higher channels take precedence over packages in lower channels.
  • Recent conda versions default to enforcing strict channel priority - this means that Packages in lower priority channels are not considered if a package with the same name appears in a higher priority channel (see Managing channels).

So if we publish new versions of fsl_sub (under that name) to conda-forge, these versions will be masked by the older versions already available on our fslconda/public channel.

The only two work-arounds to this problem that I can think of, which will not break installation of existing FSL versions, are:

  1. Publish the package to conda-forge under a different name, e.g. fslsub
  2. Publish the package to conda-forge under the same name, i.e. fsl_sub, then remove all versions of fsl_sub from fslconda/public, and retroactively re-publish those versions to conda-forge.

I would personally vote for option 1, as removing packages from conda channels can be problematic.

Edited by Paul McCarthy

Merge request reports