Sortmerna conda recipe

[biocodz]

The current recipe will be maintained parallel to the Sortmerna bioconda-recipe. The bioconda recipe currently uses pre-built binaries. The current recipe performs the whole build including building 3rd party libraries. This recipe is also going to support Windows builds (not supported on bioconda).

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/sortmerna) and found some lint.

Here's what I've got...

For recipes/sortmerna:

• The recipe could do with some maintainers listed in the extra/recipe-maintainers section.
• Selectors are suggested to take a <two spaces>#<one space>[<expression>] form. See lines [14, 34]
• license_file entry is missing, but is required.
• The extra section contained an unexpected subsection name. skip-lints is not a valid subsection name.
• The extra section contained an unexpected subsection name. identifiers is not a valid subsection name.

For recipes/sortmerna:

• Recipe with the same name exists in bioconda: please discuss with @conda-forge/bioconda-recipes.
• Jinja2 variable references are suggested to take a {{<one space><variable name><one space>}} form. See lines [9, 9, 9, 34, 35, 36].
• License is not an SPDX identifier (or a custom LicenseRef) nor an SPDX license expression.

Documentation on acceptable licenses can be found here.

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/sortmerna) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/sortmerna:

• Recipe with the same name exists in bioconda: please discuss with @conda-forge/bioconda-recipes.

[bgruening]

I don't think we should maintain the bioconda recipe in parallel. If this one is ready here we should remove the bioconda recipe.

[biocodz]

I agree. Mentioned the parallel just for suggestions. How do we proceed with removing the bioconda recipe? Usual pull request?

[martin-g]

I was not aware of this PR.
I also worked on the Bioconda recipe to build packages for more platforms - bioconda/bioconda-recipes#46644
It is a duplicated work for now! Once this PR is merged I will create an Arch Migrator PR to add builds for linux-aarch64 and linux-ppc64le and another PR for dropping the Bioconda recipe!

[biocodz]

Created bioconda-recipes PR 48607 to remove sortmerna recipe due relocation to conda-forge

[conda-forge-webservices]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/sortmerna) and found it was in an excellent condition.

I do have some suggestions for making it better though...

For recipes/sortmerna:

• Recipe with the same name exists in bioconda: please discuss with @conda-forge/bioconda-recipes.
• This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.
• In your conda_build_config.yaml, please change the name of MACOSX_DEPLOYMENT_TARGET, to c_stdlib_version!

[dslarm]

Anyone still working on this?
It looks like the recipe is deleted from bioconda, but this recipe has never been merged and landed as its own feedstock - possibly due to windows build failing? Would it make sense to kill the windows build for now, and get this working for the linux side

[martin-g]

Would it make sense to kill the windows build for now, and get this working for the linux side

+1

[biocodz]

yeah, I guess disabling Win build is an option. Do I have to prepare another PR?

[dslarm]

yeah, I guess disabling Win build is an option. Do I have to prepare another PR?

No, I doubt it: you should be able to add the commit in your existing branch, and it will automatically pull.

[github-actions]

Hi! This is the staged-recipes linter and your PR looks excellent! 🚀

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I wanted to let you know that I linted all conda-recipes in your PR (recipes/sortmerna/meta.yaml) and found some lint.

Here's what I've got...

For recipes/sortmerna/meta.yaml:

• ❌ This recipe is using a compiler, which now requires adding a build dependence on {{ stdlib("c") }} as well. Note that this rule applies to each output of the recipe using a compiler. For further details, please see META: {{ stdlib("c") }} migration conda-forge.github.io#2102.
• ❌ In your conda_build_config.yaml, please change the name of MACOSX_DEPLOYMENT_TARGET, to c_stdlib_version!

_{This message was generated by GitHub Actions workflow run https://github.com/conda-forge/conda-forge-webservices/actions/runs/12070968857. Examine the logs at this URL for more detail.}

[mfansler]

This should probably be removed. MacOS SDK is redundant with defaults. Don't linux default compilers work?

[biocodz]

I was not able to build without configuration as specified in conda_build_config.yaml

[mfansler]

Was this done together with the stdlib spec? How did it fail?

Perhaps push a version with these changes so we can see the logs from any failing CI.

[biocodz]

Linux build fails under compiler >11.4 due incompatibilities with old 3rd party c libraries used by Sortmerna. Have to stick with max 11.4 until this is resolved. Same goes for MacOS.

[mfansler]

If you want run_exports to keep parity with Bioconda standards, then use them; otherwise, tidy up.

Suggested change

	run_exports: []
	#skip: True # [osx]

[mfansler]

Another point for discussion is that this is vendoring zlib and rocksdb, both of which are available through Conda Forge. It would be preferable that the recipe be reworked to use the Conda Forge versions.

[biocodz]

Another point for discussion is that this is vendoring zlib and rocksdb, both of which are available through Conda Forge. It would be preferable that the recipe be reworked to use the Conda Forge versions.

There are problems with this:

• static rocksdb.lib is built with all possible zip libs (lz4-c, snappy, zstd, bzip2, zlib) -> need to include all of them into sortmerna build, and create the cmake modules for all (except zlib). Sortmerna only uses zlib.
• not all versions of rocksdb are available.

[conda-forge-admin]

Hi! This is the friendly automated conda-forge-linting service.

I just wanted to let you know that I linted all conda-recipes in your PR (recipes/sortmerna/meta.yaml) and found it was in an excellent condition.

[biocodz]

I'll disable Win build after checking one more time the reason for failure. Conda-build has no problems on my local machine

[mfansler]

Another point for discussion is that this is vendoring zlib and rocksdb, both of which are available through Conda Forge. It would be preferable that the recipe be reworked to use the Conda Forge versions.

There are problems with this:

• static rocksdb.lib is built with all possible zip libs (lz4-c, snappy, zstd, bzip2, zlib) -> need to include all of them into sortmerna build, and create the cmake modules for all (except zlib). Sortmerna only uses zlib.
• not all versions of rocksdb are available.

The rocksdb feedstock appears amenable to supporting specific versions as branches (see PR history). If a v7.10.x branch is needed, it could possibly be added there.

As for zip libs, I admit I don't follow the implication. So, maybe I'm not the one to discuss this with (CC: @conda-forge/help-python-c). Naively, I don't understand why anything needs to change outside of switching from static to dynamically-linked libraries.

Sorry to be a bother about this, but it just does not look great to be running 100+ minutes per platform and 90% of that time is rebuilding libraries Conda Forge nominally has available for dynamic linking.

---

Otherwise, if one wants to merge with the vendored libraries, then the licenses of those need to also be explicitly bundled through the about.license_file list. E.g., zlib license and rocksdb license.

[biocodz]

Yeah, we are well aware of the described problem, and tried to solve it, including the dynamic linking, and the pre-built libraries, and each time we ran into some kind of problem. For the time being, the existing solution is the only one, and fixing it requires a considerable effort/time. Considering this project is run at 100% voluntarily dedicated free developer's time, it's not going to happen fast.

[mfansler]

Just checking back in. Thanks for the clarifications.

Since reworking the dependencies appears tedious, let's rather ensure the zlib and rocksdb licenses are added. One could do this dynamically, but simply including copies (linked in #25438 (comment)) would suffice. Either adjust the names/paths to reflect which license corresponds to which vendored software, or include an additional file that indicates what is what.

[mfansler]

LGTM!

I'm going to leave this open a day or two, in case anyone from @conda-forge/help-python proper has comments. Otherwise, I think it's good to merge.