For some time, I have been feeling indecisive about how long I want to continue maintaining Snakemake, https://snakemake.github.io/, in Fedora. The decision to orphan Snakemake is not an obvious one, but if I am to free up some time then I must let some things go. None of the packages involved is currently all that troublesome or high-maintenance, but the number of packages involved is very high once you consider all of the Snakemake plugins and the various dependencies that I am taking care of solely to support Snakemake. Even with a low workload per package, the total effort does add up.

I also don’t love the bundle of pre-compiled assets for HTML reports, especially in light of unresolved questions like https://github.com/snakemake/snakemake/issues/3905 and https://github.com/snakemake/snakemake/issues/3841. This is not a crisis for packaging Snakemake. I believe that the way the asset bundle is packaged complies with current guidelines considering https://pagure.io/fesco/issue/3177 and pagure.io/fesco/issue/3269, and I put a *lot* of effort into fully auditing and documenting the applicable licenses. Still, it constitutes a sort of long-term liability at best, and the situation will probably worsen with time due to upstream inertia and as FPC looks to find realistic ways to tighten up the rules around such assets.

Maybe it’s all worth it, and Snakemake in Fedora is providing a lot of value to some people. I’m not really sure. Snakemake uses mixed-integer linear programming to optimize execution plans via python-pulp, and having all of this in system packages nicely exposes the system-packaged optimization solvers. But I don’t have very good insight into how people are actually using all of this in practice. Are people mostly installing Snakemake the upstream-recommended way, with pixi, instead?

In addition to the top-level snakemake package, I am orphaning the following 23 packages that are part of Snakemake. Some of these are hard dependencies for the snakemake package, and a number are useful optional plugins, mostly first-party ones written by the Snakemake developers.

python-snakemake-executor-plugin-cluster-generic
python-snakemake-executor-plugin-cluster-sync
python-snakemake-executor-plugin-flux
python-snakemake-executor-plugin-kubernetes
python-snakemake-executor-plugin-slurm
python-snakemake-executor-plugin-slurm-jobstep
python-snakemake-executor-plugin-tes
python-snakemake-interface-common
python-snakemake-interface-executor-plugins
python-snakemake-interface-logger-plugins
python-snakemake-interface-report-plugins
python-snakemake-interface-scheduler-plugins
python-snakemake-interface-storage-plugins
python-snakemake-logger-plugin-rich
python-snakemake-storage-plugin-azure
python-snakemake-storage-plugin-fs
python-snakemake-storage-plugin-ftp
python-snakemake-storage-plugin-gcs
python-snakemake-storage-plugin-http
python-snakemake-storage-plugin-s3
python-snakemake-storage-plugin-webdav
python-snakemake-storage-plugin-xrootd
python-snakemake-storage-plugin-zenodo

In addition, I am orphaning the following 14 Python packages that I have been maintaining solely because they are dependencies for one or more of the Snakemake packages above. Each of these would become a leaf package if the Snakemake packages were retired.

python-argparse-dataclass
python-conda-inject
python-connection_pool
python-dpath
python-ftputil
python-irodsclient
python-py-tes
python-reretry
python-smart_open
python-sysrsync
python-throttler
python-webdav4
python-wsgidav
python-yte

In addition, I’m orphaning the following two packages that are dependencies for python-google-cloud-storage, which I don’t maintain but which is only a dependency for packages in the above lists.

python-google-crc32c
python-google-resumable-media

All of the above packages have been carefully maintained downstream and are up to date. Some of the upstreams are not very active. In addition to orphaning these packages, I am removing neuro-sig as a group co-maintainer.

I’m holding on to the following packages for now, even though they only support Snakemake, because I have a general interest in keeping the COIN-OR optimizers packaged in Fedora. For these, too, I’m removing neuro-sig as a group co-maintainer. I might change my mind about these later. If you are interested in co-maintaining these or taking them over entirely, let me know.

python-pulp
python-pyscipopt