On 10/14/2015 12:39 AM, Christophe Demarey wrote:
Le 12 oct. 2015 à 19:22, Dale Henrichs a écrit :
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?
No, I did not check on latest Metacello versions. What is supported? There are a number of operators that can be specified on a project by project basis including ~>[1] ... there never seemed to be a big demand for these operations, presumably because so few developers adhere to a semantic versioning scheme (which makes trying to reason about version numbers very hard) ... and I think that the symbolic version naming convention invented by the Seaside guys: #release3, #release3.1, #release3.2, etc. is superior (from a practical perspective) ...
[1] https://robots.thoughtbot.com/rubys-pessimistic-operator
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? I would like to define the dependency solving as a rest service, so no need to support multiple platforms. the dependency solving can be hosted on linux.
So you can't do a build using CargoPackageManager without being connected to the internet ... As I said in another message, I think that you are trying to solve a different problem than Metacello ... there are a number of similarities in the contents of the meta data that is being used (and common specification classes at this level would probably be beneficial), but Metacello is primarily aimed at developers building and using packages produced by others ... I am taking the approach that for developers an SCM (I talk about git all the time, but any disk-based SCM can be used) is part an parcel of of not only developing your own projects but when using other projects, you inevitably have to a) customize them for your own use or b) contribute bugfixes back to the community and an SCM is required for that ...
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:) you're right but we should encourage people to adopt semantic versionning. It's very powerful when semantic versioning policy is applied.
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? What I wanted to say is that is still experimental for me because it does not have yet users. Maybe we could take Gemstone and GLASS/GSDevKit package as a use case and see if Cargo fits your needs. I would really enjoy to join forces and have a better solution. What are your requirements for having GLASS/GSDevKit loadable into GemStone. Do you have a deadline? I will have more time starting November (for now, I work on the bootstrap with Max for 2 weeks).
post-November will work best for me as I am targeting a talk on GsDevKit_home and tODE for Smalltalks in November ... I don't have a deadline, but the need to have FileTree and Metacello-lite integrated in the base GemStone is bubbling close to the top ... and post-November would be a good time ... Dale