Orthogonally to the process open dev / release, we have the notion of
two different uses of Configurations.
I call them the Projects vs the Dependencies style.
Let us look at these two uses. I will take an example that is not in
Moose but we can see the exact
same problems in Moose.
There is a parallel with XMLSupport (a group loading XMLparser, writer,
SIXX, Pastell....
and XMLParser, XMLWriter
XMLSupport is a "Project" configuration: it is a convenient way to
group and load (in particular it expresses
dependencies to clients of XML) so the relation is not I load Sixx
because I dependent on it.
More I load it because I want to optionally offer it.
XMLParser is a "Dependencies" configuration: to parse XML we need
OrderedPreservingDictionary, Bitmap...
if we do not load them we cannot get XMLParser working.
Why this difference is important: When you want to build a tool using
the XMLParser you do not want to get SIXX. pastell
when you do not need it.
Based on this analysis we see that
PetitParser project, MooseIDE project are Projects
while
PetitParser (the package), MooseCore (the package) are dependencies
configuration.
Now the problem is that we do not have a simple way to express the
dependencies at the level of a package.
Because when coding the XMLParser package you would write that it
depends on SIXX.
Christophe is working on a prototype to get package dependencies
expressed at the package level
and he will present that at ESUG but this is not ready to use.
Now we could (but this is a lot of work) add a
configuration"Dependencies" to any package. These dependencies would be
really simple. We already have that for Traverser, Merlin, RoelTyper and
many others.
This way we could have
- Project configurations
- Dependencies configurations
Now I would like to see is do we do it? Would be good to have different
names to identify these configurations clearly.
Or at least have a description that clearly say it.
Stef
Name: Famix-Core-usmanbhatti.237
Author: usmanbhatti
Time: 1 July 2014, 4:15:42.620954 pm
UUID: a3822a71-e6f7-4d21-abc1-bab82b31b9dc
Ancestors: Famix-Core-MirceaLungu.236
refactoring the common behavior to query dependencies in a paradigm
agnostic way and creating a new trait to compute dependencies of
object-oriented entities.
This refactoring was necessary to reuse moose chef queries for non object
oriented systems that do not have inheritance. Tests are green.
usman
Hi alex
Why Roassal depends on FuelMetalevel?
- having the stable as a baseline is not nice because clients will cry
big times.
- there is no correct version and it would be good to use versionner to
manage it
and to release some versions from time to time. Now that roassal2 is out
it is importnt that people
can build on versions if they want.
Typically Synectiquers should really pay attention to this "detail"
- unique version is pure junk and looks like from a tutorial so I can
clean it.
- versionDevelopment: introduce a dependencies to FuelMetalevel.
I do not have access to it but I can clean it fast. Else I will fork it.
Stef
Apparently it is disabled. Is this intended?
Cheers,
Alexandre
--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>Now the problem is that we do not have a simple way to express the
>dependencies at the level of a package.
AFAIK, we can express that pretty good with groups and
package requires in Metacello.
Stephan
My assumption is that in changing configurations,
we don't break older versions and versions for other platforms.
Sometimes we only fix things for specific (newest) versions,
but otherwise keep them intact.
We've started looking at the changes made, and that
principle is not respected. Please note that at the moment
Versioner cannot reliably be used to version configurations that
use platform tags.
The change in ConfigurationOfXMLWriter broke the build.
Diego reverted the change.
Stephan
Hi
today we brainstormed and I will send a sequence of emails to discuss
what we decided
and started to do.
One of our goal is to check if we can use versionner to manage all the
configurations.
It looks possible.
The first things we started to do is
- make sure that all the configurations of external libraries are
correctly defined.
In particular we made sure that a version does not depend on a
stable one but on a version specific.
- We think that Moose should not depend on baseline of external
tools, because we need real reproduceability.
- We started to produce configurations with versionner that do not
depend on stable but on exact versions.
- I will continue to see if we can use Versionner because it would
simplify the release.
Stef
