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:) Dale