Open peterbygrave opened 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.
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
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?
@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?
@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:
@greglandrum a statically linked cartridge is an opportunity that would be easily available with a dedicated recipe, but indeed not a requirement.
@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
@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.
@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
@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 🚀
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:
<16
- see here. This might plagued any next release ofrdkit
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!