Le 12 oct. 2015 � 14:03, Thierry Goubier a �crit :

2015-10-12 11:20 GMT+02:00 Christophe Demarey <Christophe.Demarey@inria.fr>:

Well, the point is not to replace metacello but to go towards a per package metadata description allowing some flexibility with the introduction of virtual packages.
This will allow, in a first time, to set up a package repository and more important, a web site on top of it. In a second time, I also want to enable more flexibility in expressing dependencies constraints (eg. > 2.0, 3.*, etc.). To achieve that, you need a very performant dependency solver and I would like to reuse linux ones (it has be done for ocaml by example) through CUDF (check http://mancoosi.org/).

For now, I implemented a simple solver for static dependency constraints (=1.2). I checked Metacello implementation and it looked to me that approaches are a bit too far to be able to reuse the whole code. For sure, it is not as robust as Metacello is, because you enhanced it for years.
What I want now, is to experiment (let's name it) Cargo Package Manager to see if it fits the needs. Pharo bootstrap is the first use case.

What I would like, is that, at the end, the dependency solver get out of Pharo and that we use already existing linux ones. What will stay into Pharo are packages metadata and the way to load a list of packages.

This is something I don't understand: why this focus on making this out of Pharo?

The focus is not there but I'm not a specialist of Constraint Satisfaction Problems (CSP), I'm not aware of CSP implementation in Pharo and so, I just want to reuse something working fine for years. We are not so much in the community and we should take care to do not have to maintain too many things, especially when it has little added value.

What CUDF shows is that, overall, a package dependency problem can be expressed as a SAT problem which is then solvable by the appropriate solver... For example, in my ubuntu, I see that I have three (!) CUDF dependency solvers (mccf, packup, aspdcup), where mccf can use the following underlying solvers: lpsolve, cbc, Cplex, Gurobi, Glpk, SCIP or WBO (!).

right

More interesting is packup, which rely on minisat+. Minisat, with a short search, shows up as 600 lignes of C++ (https://github.com/niklasso/minisat or http://minisat.se/). Why not porting Minisat in Pharo then?

could be an idea. Also good to know, all CUDF backends does not have the same speed.

I keep that in mind. It would be good to have a CSP solver available in Pharo.

You would simplify your building your dependency issues (no need to link Pharo to yet another external tool which only works on Mac OS X / Linux :( )... And that would make such a solver available for other uses.

My idea was to provide the solving facility as a Rest service and so, do not have to care about OS portability.

(I think Metacello could switch to using Minisat if a Smalltalk port was available... )

In the mean-time, the number of available CUDF tools in Linux shows probably nice integration issues with dependency loading depending, on some cases, on the solver selected... cool :(

oh ...