On 10/12/2015 01:42 AM, Christophe Demarey wrote:
Hi Dale,

Le 11 oct. 2015 � 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, but I am curious how you think "package dependencies" will play with git-based projects?

Dependencies are not tied to a Version Control System (monticello, git or whatever). Dependencies are a package concern.
With a released version, at the end, we need to fech source code from a VCS (as we do not have a shared binary format): these steps are already done by MC*Repository classes, including git.
Yes but I am asking specifically how this link is specified ... in Metacello, you use repository descriptions to identify the source repository. I am curious how you specify these cross repository dependencies ... or do you even support cross-repository dependencies?

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.

Git allows you to easily reference a set of packages working together. It works fine for packages of the same repository but you get back the problem since you deal with packages of other repositories.
right and in Metacello the cross-repository specifications is handled by a project spec:

� spec
��� baselineOf: 'Seaside'
��� repository: 'github://SeasideSt/Seaside:v3.2.0/repository'

In this case the git version is specified as part of the repository spec (v3.2.0 is a git tag) ... it gets back to how do you handle cross repository references?

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 ....

For the first step of the bootstrap, it will work but not for next steps where we will split the Pharo image into different projects.
and how are project dependencies handled? It seems that the project dependencies are intimately tied to package dependencies as often the project dependency itself comes from a specific set of packages and needs to be specified at the package level ...

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.

When you develop, you have a working copy of a package meta-data, including dependencies. Actually, there are current dependencies of the package. You could avoid to refer to specific versions and just point to the package name as your working image should already have packages loaded. (kind of configurationOf baseline)
This is a BaselineOf in Metacello ... and does exactly what you talk about here ...
When you release a version (strong act), then you "freeze" the current working version of the�package meta-data and you publish it somewhere (a package repository) so that it becomes available to others. This metadata is not source cod, is easily accessible by tools and it becomes easy to build a web site on top of this to search / promote packages.
So, the problems I'm trying to solve there are:
  • do not be tied to a VCS and do not need to load code to "play" with packages metadata
As I've mentioned in another message, there is no reason other than a lack of tools that the Metacello specifications (ConfigurationOf and BaselineOf) are not stored in XML/JSON/STON files ... I never liked the idea that code had to be loaded, but it was expedient at the time ...
I am curious about your use of the term "package" here ... is this "package" as in Monticello package, or "package" as in a collection of packages and project dependencies ... or ConfigurationOf or BaselineOf?
  • do not mix preoccupations: I do not want to have metadata of all released versions + working copy of a package at the same place
Have you looked at a BaselineOf?

�I also don't like the fact that ConfigurationOf has release and version information embedded in it ... but the ConfigurationOf was invented to plug the gap between what was available in the Monticello eco-system and what is available in a full-featured scm like git.

The BaselineOf was invented because git was able to take care of all of version relationships and Metacello no longer needed all of that junk.

If you look at a BaselineOf you will see that it is reduced to a single baseline method with package dependencies specified by name (the entire BaselineOf applies to all of the packages in a directory on disk managed by git or whatever) very simple very compact and very easy to maintain ... the only reason one touches a BaselineOf is to change a dependency....

So I think that for what you seem to need all that needs to be done is to define an XML/JSON/STON representation for the data in a BaselineOf ... a generator for a different format could easily be written and could take existing BaselineOf and spit out the data ...

Dale