Sortmerna conda recipe
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).
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-maintainerssection. - 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.
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.
I don't think we should maintain the bioconda recipe in parallel. If this one is ready here we should remove the bioconda recipe.
I agree. Mentioned the parallel just for suggestions. How do we proceed with removing the bioconda recipe? Usual pull request?
I was not aware of this PR. I also worked on the Bioconda recipe to build packages for more platforms - https://github.com/bioconda/bioconda-recipes/pull/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!
Created bioconda-recipes PR 48607 to remove sortmerna recipe due relocation to conda-forge
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 https://github.com/conda-forge/conda-forge.github.io/issues/2102. - In your conda_build_config.yaml, please change the name of
MACOSX_DEPLOYMENT_TARGET, toc_stdlib_version!
filed issue 5391 on conda-build
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
Would it make sense to kill the windows build for now, and get this working for the linux side
+1
yeah, I guess disabling Win build is an option. Do I have to prepare another PR?
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.
Hi! This is the staged-recipes linter and your PR looks excellent! :rocket:
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 https://github.com/conda-forge/conda-forge.github.io/issues/2102. - ❌ In your conda_build_config.yaml, please change the name of
MACOSX_DEPLOYMENT_TARGET, toc_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.
Another point for discussion is that this is vendoring
zlibandrocksdb, 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.
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.
I'll disable Win build after checking one more time the reason for failure. Conda-build has no problems on my local machine
Another point for discussion is that this is vendoring
zlibandrocksdb, 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.
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.
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 https://github.com/conda-forge/staged-recipes/pull/25438#issuecomment-2511219960) 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.