conda-forge / rdkit-feedstock

A conda-smithy repository for rdkit.
BSD 3-Clause "New" or "Revised" License
8 stars 21 forks source link

Adding rdkit-postgresql package #128

Open peterbygrave opened 1 year ago

peterbygrave commented 1 year ago

Comment:

Hi rdkit maintainers 🙂

I have just got a staged-recipes feedstock to build for rdkit-postgresql: https://github.com/conda-forge/staged-recipes/pull/22415/.

Two items came up:

  1. Should it exist as a separate package from rdkit? comment in PR
  2. There is a problem with the libcxx v16 (released 29 March 2023) for osx builds. I had to pin to <16 - see here. This might plagued any next release of rdkit on this repo. I'm not sure if this is caused by the interplay between the local and include versions of boost - I found the stack trace a little tricky to read.

If you do agree that rdkit-postgresql should be separate, please could you comment over there and express any maintainer interest 👍

Many thanks!

greglandrum commented 1 year ago

As I commented in the other PR, I think it would make sense to add it to this feedstock so that we only have one place to worry about.

peterbygrave commented 1 year ago

That sounds awesome, will close the staged-recipes PR.

I am unfamiliar multiple outputs (which might requiring knowing the differences between the build artifacts). Is there anyone that could easily do this work? No problem if not 🙂 I can take a bit longer via trial-and-error approach

rvianello commented 9 months ago

I would be actually in favor of a dedicated conda recipe for the postgres cartridge. Maybe there is something I'm still missing about how subpackages work, but I have the impression one would need to also split the C++ and python parts, in order not to install the python stack as a dependency. In contrast, a dedicated recipe would in general allow reducing the build to the components the cartridge uses, and also use static linking to simplify the deployment. Maybe a dedicated recipe would increase the number of things to worry about, but I'm not sure adding the cartridge to the rdkit recipe would make things simpler. Would the build matrix multiply by the number of supported postgres versions?

greglandrum commented 9 months ago

@jaimergp : isn't it possible to add another set of output packages (for the rdkit-postgresql bindings) to this feedstock so that we don't have to set up something separate?

greglandrum commented 9 months ago

@rvianello if the deployment happens using conda, do we need to worry about simplifying the deployment with static builds?

It seems like we could reasonably easily have:

rvianello commented 9 months ago

@greglandrum a statically linked cartridge is an opportunity that would be easily available with a dedicated recipe, but indeed not a requirement.

jaimergp commented 9 months ago

@jaimergp : isn't it possible to add another set of output packages (for the rdkit-postgresql bindings) to this feedstock so that we don't have to set up something separate?

Yep, that's supported. We just need to check which naming conventions apply. Possibly librdkit instead of rdkit-cpp is preferred. There's an ongoing conversation on the boost feedstock about it: https://github.com/conda-forge/boost-feedstock/pull/164

skearnes commented 2 weeks ago

@peterbygrave @greglandrum can I help get this over the finish line? It would be very helpful to have for my work on the Open Reaction Database.

skearnes commented 1 week ago

@rvianello if the deployment happens using conda, do we need to worry about simplifying the deployment with static builds?

It seems like we could reasonably easily have:

  • rdkit-cpp: the include files, shared libraries, data files, etc.
  • rdkit: the python wrappers, depends on rdkit-cpp and all the python dependencies
  • rdkit-postgresql: the postgresql cartridge, depends on rdkit-cpp and postgresql

Please take a look at #158

peterbygrave commented 1 week ago

@rvianello if the deployment happens using conda, do we need to worry about simplifying the deployment with static builds? It seems like we could reasonably easily have:

  • rdkit-cpp: the include files, shared libraries, data files, etc.
  • rdkit: the python wrappers, depends on rdkit-cpp and all the python dependencies
  • rdkit-postgresql: the postgresql cartridge, depends on rdkit-cpp and postgresql

Please take a look at #158

Thank you

I'm not familiar enough with the rdkit build process to help on that PR, but it is looking awesome 🚀