On 10/11/2015 11:10 PM, stepharo wrote:
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 ...
Yes but we want them per package.
We do not work on that since more than one year by accident.
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 ...
I know what I meant was use of pragmas, chaining pragma, loading all
the configuration information (different baselines....).
Yeah, I meant that too ... I believe that the entire Metacello
specification (ConfigurationOf and BaselineOf) can be represented in an
XML/JSON/STON file modulo all of the extra methods that folks have
tacked onto the ConfigurationOf for conevenience... but I don't consider
that extra stuff part of Metacello ... while chained pragmas, etc. can
be represented in XML/JSON/STON files, the primary reason that they are
present is to support the ConfigurationOf ... a BaselineOf is typically
a single method and doesn't use all of that extra stuff ...
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.
I see well the reason. :)
The last point is the most tricky one when we have per package
dependencies. But I will let christophe answers.
It's the reason that I think per package dependencies (at least embedded
in the package structure itself) is a bad idea ... it not only gets in
the way of cross platform usage, but for the more complicated projects
you end up having to touch a bunch of different files to make a "simple
dependency change" not to mention having to edit different versions of
the same package that may participate in different/conflicting
dependency chains ...
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 ...
I will let christophe answer.
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!
Thanks. We will need help definitively.
I have been looking at what would need to be done to "port Metacello" to
the base GemStone product so that the GLASS/GSDevKit packages could be
loaded "directly" into the system, as opposed to the current route,
which has a fair amount complicated bootstrapping involved ... I would
be using only BaselineOf so the it would not be necessary to port all of
Metacello to the base GemStone product ... While I think that I can
carve out a "minimal Metacello" it wouldn't be completely free of
complication, since I have a commitment to keep the old Metacello
functioning and I cannot afford to support two independent versions of
Metacello ...
If instead I worked with Christophe on this project (and it would meet
my needs) then I would save myself a fair amount of work:) And part of
that savings would be invested in building a Metacello-bridge to the new
packages so that there would be a smooth transition ...
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:)
:)
It's the same reason I don't read comments in the code .... when you
read the code, you get to see what is actually being done as opposed to
what the developer (or comment writer) wants you to think is being
done:) Often there is a disparity between what the comment says and what
the code does and in my experience the code always seems to win:)
Dale
