Christophe,
I still don't have a lot of time to read the paper and try to understand
what you are trying to accomplish, 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.
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.
Dale
On 10/6/15 11:47 PM, Christophe Demarey wrote:
Hi Dale,
Le 6 oct. 2015 à 20:23, Dale Henrichs a écrit :
On 10/6/15 5:10 AM, stepharo wrote:
Le 6/10/15 11:40, Stephan Eggermont a écrit :
On 06-10-15 11:11, stepharo wrote:
I will do a separate configuration of magritte seaside.
You need to load the correct groups. Separate configurations are a bad practice
and should be eliminated, not encouraged.
I totally disagree.
And groups are not supported by the configurationBrowser
The configuration has a lot of essential complexity, as many different
combinations of components are needed in different situations. We need tools
that recognize that essential complexity and support it, not tools that try to
hide it and then have no practical usability.
Well I disagree. And all the effort of christophe for the new dependencies
declarations at the package level just goes in that direction.
I will do a MagritteSeaside Configuration that I will maintain and I will also
do a MagritteTutorial one.
Stef,
I hope you and Christophe are considering cross platform considerations when implementing "new
dependencies declarations at the package level" ... MonticelloConfigurations had "package level
dependencies" and the implementation was extremely rigid to the point where it wasn't possible to
substitute an alternate (platform-speicific) package in the package graph without creating new package
versions of all packages in the graph ... Of course I am not aware of the approach that Christophe, but be
aware that "there be dragons there":)
Thanks for the warning. cross-platform packages are integrated into this new
approach by allowing to express dependencies to virtual packages (idea from
debian OS:
http://www.debian.org/doc/debian-policy/ch-binary.html#s-virtual_pkg). It
allows low-coupling and is very flexible.
You will find more information in the paper published at IWST'14:
https://hal.inria.fr/hal-01086083/document (by the way, you should already have
it, I sent it to you last year but you were very busy at this time ;) )
To summarize in a few words, we want dependencies expressed at the package
level (and we want more meta-data on packages), 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).
We also want to detect dependencies automatically as much as possible to avoid
missing or not-used dependencies (dependency analyser tool). All together, it
will allow to define architectural rules and layers in Pharo. I now
experimenting all that with the Pharo bootstrap.
If you have any question or remark, do not hesitate to ask or to give feedback.
Christophe.
