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? > 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. > 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). Christophe
smime.p7s
Description: S/MIME cryptographic signature
