This came up in a number of issues and also in the experimental PR #30.
I am planning to move the library from a Cython-based implementation, in which a Python extension module is built that links directly against the Concorde library, to a subprocess-based implementation, where the library calls Concorde in a subprocess. I am normally more in favor of the first approach because it is more efficient and more easy to manage (everything runs in the same process, there is no need for serialization/deserialization, etc) but in this case the second approach has some clear advantages:
- While Concorde makes an API available, it is clear that the solver is principally meant to be called through the executable. This has lead in the past to a few cases where the tour computed by the Concorde executable was different from the tour computed with this package.
- The format to present a TSP instance and to return a computed tour are fairly standardized, and are easily supported in code (using e.g. the
tsplib95 library). Having these interfaces exposes an "escape hatch" for debugging or to access a feature that is not exposed through the code: simply take the TSP specification and run the Concorde solver manually.
- The build process simplifies a bit, as there are compiled binaries available for e.g. Windows.
- Other solvers, like LKH, can likely be supported with the same API.
At the time of writing some parts of the subprocess API are already present in main but they have not been documented. The plan for moving completely to the subprocess API is as follows:
This will be done in such a way so that the impact on existing users is minimal (while the new API is being added, the old API will remain functional, and after the new API has been formally released, the old API will remain available in maintenance mode on the 0.1.x branch). However, the new API will not be identical to the old API.
This came up in a number of issues and also in the experimental PR #30.
I am planning to move the library from a Cython-based implementation, in which a Python extension module is built that links directly against the Concorde library, to a subprocess-based implementation, where the library calls Concorde in a subprocess. I am normally more in favor of the first approach because it is more efficient and more easy to manage (everything runs in the same process, there is no need for serialization/deserialization, etc) but in this case the second approach has some clear advantages:
tsplib95library). Having these interfaces exposes an "escape hatch" for debugging or to access a feature that is not exposed through the code: simply take the TSP specification and run the Concorde solver manually.At the time of writing some parts of the subprocess API are already present in main but they have not been documented. The plan for moving completely to the subprocess API is as follows:
This will be done in such a way so that the impact on existing users is minimal (while the new API is being added, the old API will remain functional, and after the new API has been formally released, the old API will remain available in maintenance mode on the 0.1.x branch). However, the new API will not be identical to the old API.