coin-or
File content mismatch between releases and repo
Hi,
First of all, I would like to thank the maintainers for this large project.
I'm trying to make python-mip available in conda (here), I think we are very close to making it.
I noticed that some release files are different from this repo, even for changes made a long time ago.
An example is src/Makefile.am from master and of the latest release, this is not a big deal because I can change which library I'm linking python-mip to.
However, some from src/Cbc_C_Interface.cpp is missing in the release; for example, Osi_getIntegerTolerance in master, for reference the Cbc_C_Interface.cpp from the latest release.
This is a problem because the coin-or-cbc conda package is built from the release version, and python-mip uses Cbc_C_Interface.h/cpp.
Is it the mismatch between the files intentional or a bug it could be fixed?
Thanks.
By design, there are a lot of changes in master that have (still) not yet been released because significant work on master is still required before v3 can be released. See #465 for some info— maybe more recent explanations exist.
Until then, maintenance release such as 2.10.11 are done to fix issues, but on the original v2 baseline. I hope I got this right.
Does this answer your question?
Thanks @jhmgoossens , it answers my question. Is there a checklist with the issues missing to be done with this? I'm a bit concerned that this won't get finished soon, and it might be better to use SCIP for MIP in Python if I need conda.
I’m not aware of a list with open tasks. I’d not assume this is resolved quickly.
This is a problem because the coin-or-cbc conda package is built from the release version, and python-mip uses Cbc_C_Interface.h/cpp.
Apologies if I’m misunderstanding, but it sounds like this is the root cause: these two are mixing release and master branch source code? IMO, that is a bad idea: either stick to using releases, or build using the bleeding edge master(s) but don’t mix (at least not for the same package).
Why not stick to release and live with its limitations, such as no Osi_getIntegerTolerance? Or creating your fork and porting some features.
Maybe @tkralphs can offer some more insight?
Indeed @jhmgoossens, sticking to one would be better. However, python-mip has been compiling from master for a while, and I'm not a maintainer of that package, just a user. So I think this ship has sailed a while ago.
Unfortunately, they are getting mixed when I try to build from conda-forge because libCbc is built from the release while python-mip expects from master.
I don't think there's an easy way out since conda-forge won't accept duplicating libCbc inside python-mip package.
The list of things that need to be done is in #374, which should be copied over to a new PR. I decided to merge what was done so far, since it was in a reasonable state and I wanted people to start using and testing it before doing more and no one was looking at the refactor branch itself.
The issue you're bringing up has been discussed a few times and if you poke around issues of both this repo, the python-mip repo and the conda-forge Cbc repo, you should find some additional information. I believe it was possible to use python-mip with Cbc 2.10 at some point in the past. Perhaps this is no longer the case with more recent changes, but it's something to look into. Also, I think it was mentioned that creating some kind of "release" on conda-forge from master is possible.
Of course, getting a new stable of Cbc is the best option and for that, help is still needed. I'll try to poke at all this a bit, but my bandwidth is limited.
