On 10/12/2015 02:20 AM, Christophe Demarey wrote:
Le 11 oct. 2015 à 18:42, Dale Henrichs a écrit :
On 10/11/15 12:19 AM, stepharo wrote:
Le 11/10/15 00:40, Dale Henrichs a écrit :
Christophe,
I still don't have a lot of time to read the paper and try to understand what
you are trying to accomplish,
you should read it. :)
We wrote it for that and it is not boring nor long.
I scanned through it at the time and as I recall, I thought that the
functionality described was already covered by git and BaselineOf ... but I did
not read it in great detail and I did not (and still don't) have the time to
compose a long-winded response:)
but I am curious how you think "package dependencies" will play with git-based
projects?
In git-based repositories I don't think you have the same type of dependency
issues that one might have with monticello repositories --- In a monticello
repository you have a whole range of possible package versions to pick from,
but in a git-based repository the range of package versions is fixed to those
that are committed together so the packages that are meant to work together are
committed together.
I think that this is only true for packages committed within the same repo.
Now between porjects published in different repo you have to express them.
I do not think that we all want to publish in the same repo and clone out
everything.
... and inter-project dependencies is what a BaselineOf does .... which brings
me back to the conclusion that I reached when I scanned the paper:)
In the bootstrap scenario, you would only have one version per package to
choose from, so the packages that are meant to work together are committed
together ....
I guess I don't know what you mean when you say:
we want to decouple a released version of a package from the working copy of
the package version description (implies the creation of a package repository +
a web interface on top of it to promote/search packages).
Perhaps a description of the problem being solved would help me understand.
We want to be able to have a package market place where tools can grab
dependencies without to load code
and can compute the set of packages that should be loaded.
When a package is released into the market: then it externalise its metadata so
that a crawler can automatically build
dependency graph and create specific distribution.
Okay. This is a problem .... but it happens to be a problem that Metacello "can
solve/does solve" - so there must be something else (a deeper problem?) that I don't
quite understand.
With that said, if you are planning to replace Metacello, then I am excited:)
But I will repeat that I hope that you are considering cross platform issues ...
Perhaps at this point in time, I'd like to read some code. Then I can skip
reading the paper and get a feel for how hard it will be to port to GemStone:)
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.
Oh darn, you mean I have to continue to support Metacello:)
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/
There are a couple of different schemes for expressing "version ranges"
in Metacello. Have you looked at them?
By reuse, do you mean that you will reimplement the algorithms in
Smalltalk or are you suggesting that depency resolution will only work
on linux?
From a practical perspective I am curious what problems will be solved
by having "dependency constraints" expressed by anything more
complicated than what I use for github:
github://dalehenrich/tode:v0.0.?/repository
Which translates to load the latest patch version of the tode project
(where major.minor.patch) ... I know that in theory more complicated
schemes are intersting, but that assumes that the developers assigning
version numbers are actually adhering to a rational version numbering
scheme and from a practical matter even the above pattern is risky
business:)
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.
okay, so this is just in the experimental phases .... so for the time
being I should be focussing my efforts on the minimal Metacello approach
rather than get involved in the Cargo Package Manager?
Dale
