Split package

[wolfv]

This package contains 5 different packages (Cbc, Cgl, Clp, CoinUtils and Osi).
This is annoying because it makes it

a) hard to find (I started looking for coinutils and didn't find anything)
b) I am not sure what versions of the above mentioned packages are actually shipped here ..?

I have seperate packages here: https://github.com/conda-forge/staged-recipes/pull/10935/files

However, @isuruf already closed the PR since the contents are already here.

Can we split the cbc package into the 5 sub-packages by any chance? I am doing this because I wanted to package google or-tools which require these packages, and a CMake file (which is why i have patched a cmake file).

[scopatz]

Yeah, I am very open to splitting this up, and maybe keeping this as a metapackage. It should probably (initially) be done as just adding outputs to the recipe in this feedstock

[wolfv]

@scopatz I have been thinking about how to do this best...

I have the bunch of recipes that I need for google-or tools here: conda-forge/staged-recipes#10935

How would you feel about creating 5 new feedstocks with these (arguably) better naming scheme (modeled after fedora/debian) so that the new names would be:

coin-or-utils
coin-or-cdc

etc.

and once we have them in place we modify this package, and make it a alias (meta-)package that just run-requires coin-or-cbc, and we archive this feedstock?

[scopatz]

I am fine with creating new feedstocks if you want and then modifying this to be a metapackage (we shouldn't archive it though).

However, you could do effectively the same thing here by having multiple outputs in this recipe. That seems like the better option if all of the packages come from the same tarball and we are splitting it up in a more sensible & modular way.

I am fine either way, though!

[wolfv]

Hey @scopatz,

cool. They don't come from the same tarball necessarily -- in my recipes I used the github releases: https://github.com/coin-or/Cbc/releases

I was under the impression that this would be nicer -- also for the bot to pick it up automatically etc.

What do you think?

[wolfv]

PS: E.g. I specifically need an older version of (I think) cbc (0.107.14 instead of 0.107.15 or something like that).

[scopatz]

Ahh great, yeah then if they don't come from the same tarball, different feedstocks seems like the right way to go

[tkralphs]

Hi all, I was just poking around to see if there's been any progress getting Cbc on conda-forge in the split configuration and happened on this discussion. It would be great to move this forward, as I'd also like to have CyLP, which depends on Cbc, on coda-forge (see coin-or/CyLP#77).

Getting tarballs from Github is probably the way to go, as archiving source to https://www.coin-or.org/download/source/Cbc/ will be deprecated now that we are fully on Github (at the moment, the scripts for doing the archiving are actually broken, as they fetch the source from the old SVN, which is no longer updated). As an aside, tarballs for individual packages have always been available from https://www.coin-or.org/download/pkgsource/Cbc/, since the split packaging is utilized by the Linux distros.

There won't be much choice about the split packaging soon, as Cbc 3.0 will be coming out and utilizes a simplified build system that no longer includes the top-level configure script and Makefiles for locating building dependencies (they are replaced by the package manager coinbrew.

Anyway, I'm happy to help as needed. Seems like @wolfv has a good starting point, but I would prefer not to use CMake, as this is not our native build environment.

[scopatz]

All PRs welcome!

[wolfv]

Hi @tkralphs thanks for poking on this conversation. Yes I am still of the opinion that we should do it!
Do you want to make a PR based on my recipes?
You can find them here: https://github.com/wolfv/staged-recipes/tree/add_coin_or/recipes

I have no issues if you choose to not use the CMake based build tools, but it might be more tricky to get it working smoothly for win.

[tkralphs]

My COIN-OR TODO list is very long at this point, so I would be very happy to advise someone else who is willing to take this on. If you wait for me, it may be a while. My conda knowledge is also not very good. I would be happy to write down what I think the basic recipe would be---it should be similar for all projects. It should also be possible to start by looking at the corresponding homebrew recipes.

As for supporting Windows, I don't know the best approach. The primary things you need are a bash interpreter, make command, etc., which seem to already be available on conda-forge. I guess we can cobble together a build environment from conda-forge projects, which would be very cool. Of course, if we need to use CMake, that is OK, it's just also not something I know very well.

[wolfv]

ok then let's do it based on my previous recipes and use the regular build methods. I'll open a PR to staged-recipes and will ping you for comments.

[BastianZim]

Hi @conda-forge/coincbc just as a heads-up, conda-forge/coin-or-cbc-feedstock#11 should be finable able to replace this one.