On 10/11/15 11:40 AM, stepharo wrote:
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:)
Yes probably but you have to have a BaselineOf for every package. Because we want to have the dependency expressed in every package and not in a gigantic "project" configuration of.
If you are talking about ConfigurationOf, then I agree that they can be gigantic, but 99% of the junk in a configuration is completely eliminated when you use a BaselineOf ... 99% of the junk in a configuration is dedicated to plugging the gap between monticello as an SCM and built-in capabilities for git ... A BaselineOf has a single baseline method and only the "pure" dependencies amongst the packages and projects needs to be expressed ... and these dependency specs are about "as small" as you can get ...
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. But you have to load the configuration and somehow execute it so that it computes the dependencies and we do not want.
Do you recall that I have been reminding folks that the specifications for ConfigurationOf and BaselineOf will someday become an XML file? ... I have taken great pains over the years to preserve this "expectation" ... Remember the choice to use classes was made as a bootstrap convenience to avoid having to create tools ... 6 years later and there is still a dearth of tools:) When you "execute" the code in a ConfigurationOf or BaselineOf, a completely separate data structure is constructed using a well-defined API and it is this "data structure" that does the real work ... it would be very easy to convert a BaselineOf into an XML/JSON/STON file without losing any information, unless you've have disregarding my warnings:) There is nothing in Metacello "project specifications" that _depends_ upon executing code ...
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 ... Yes we do. First we wanted to make it work. Then we should have kind of virtual packages that act as platforms or project level
When you talk about "virtual packages", I would say that a BaselineOf is pretty much a "virtual package" already. When it comes to cross-platform support there are several factors that were built into Metacello from the very beginning: - it should be possible to USE a package on a different platform than it was originally written for without modifying the package itself - it should be possible to SUBSTITUTE a platform-specific package with another platform-specific package without modifying either of the packages - it should be possible to CHANGE the package dependencies based on platform-dependent requirements without modifying any of the packages The key here is that if one needs to change a package to use it on a different platform then you lose the ability to share source code. The BaselineOf satisfies these requirements, because the "project meta data" is separate from the package/source code and the BaselineOf itself is cross-platform. If you haven't thought about these issues from the very beginning, then it may not be easy to shoe-horn support in after the fact ... With all of that said, I really do love the idea of not having to support Metacello anymore:) So I would like to see you succeed with your effort!
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:) I do not know where christophe save his code but it is be public.
I may not have time to read a paper ... but I would have time to read code:) Dale