You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This is a meta issue to plan the isolation of libsolv and the definition of a new solving interface.
Breakdown
A -solv-cpp Safe and useful wrapping of libsolv
The goal is to build self contained C++ wrappers around libsolv that makes it safer and consolidate verbose patterns into utility functions.
Things such as:
RAII and value semantic
Iterators
Visitors (to replace macros)
But not:
Mamba specific logic
Context
Any #include from other mamba headers
Wrap all libsolv functions for the sake of wrapping
Hide the original libsolv object (because only selected functions would be wrapped).
All this wrapping will be private to Mamba. Current MSolver, MPool... will make use of these new wrappers but keep their interface. This will help getting some code outside of the current implementation to keep only the Mamba logic.
B- Specs ownership
Currently, version comparison, matchspecs, even repodata.json parsing is done in libsolv.
This leads to duplication (e.g. mamba::MatchSpecs), and difficulty to evolve (let alone lack of unit testing).
Right now, some functions such as MSolver::add_channel_specific_job, implement custom libsolv logic when this could be handled (and unit tested) through proper abstraction (MatchSpecs, Version...).
The goal is to implement and test (with conda test cases) these abstractions and use them in libsolv through function callbacks (need to send PR on libsolv to make it possible).
The repodata would also be read by Mamba and the packages added explicitly into libsolv.
C - New solving interface
Once all abstractions are in place, libsolv is only used as a SAT solver. We can design the new solving interface that we would like.
There would be a generic interface (or trait). All solvers, starting with libsolv and other in the future, would implement such interface, hiding all their dependencies. This would make it possible to switch solver without any code change, possibly even at runtime (which shows that things are properly abstracted).
To be completed for more details on the new interface...
The text was updated successfully, but these errors were encountered:
This is a meta issue to plan the isolation of libsolv and the definition of a new solving interface.
Breakdown
A -
solv-cpp
Safe and useful wrapping of libsolvThe goal is to build self contained C++ wrappers around libsolv that makes it safer and consolidate verbose patterns into utility functions.
Things such as:
But not:
#include
from other mamba headerslibsolv
functions for the sake of wrappinglibsolv
object (because only selected functions would be wrapped).All this wrapping will be private to Mamba. Current
MSolver
,MPool
... will make use of these new wrappers but keep their interface. This will help getting some code outside of the current implementation to keep only the Mamba logic.B- Specs ownership
Currently, version comparison, matchspecs, even repodata.json parsing is done in libsolv.
This leads to duplication (e.g.
mamba::MatchSpecs
), and difficulty to evolve (let alone lack of unit testing).Right now, some functions such as
MSolver::add_channel_specific_job
, implement custom libsolv logic when this could be handled (and unit tested) through proper abstraction (MatchSpecs, Version...).The goal is to implement and test (with conda test cases) these abstractions and use them in
libsolv
through function callbacks (need to send PR on libsolv to make it possible).The repodata would also be read by
Mamba
and the packages added explicitly into libsolv.C - New solving interface
Once all abstractions are in place, libsolv is only used as a SAT solver. We can design the new solving interface that we would like.
There would be a generic interface (or trait). All solvers, starting with libsolv and other in the future, would implement such interface, hiding all their dependencies. This would make it possible to switch solver without any code change, possibly even at runtime (which shows that things are properly abstracted).
To be completed for more details on the new interface...
The text was updated successfully, but these errors were encountered: