On 10/14/2015 12:15 AM, Christophe Demarey wrote:

Le 12 oct. 2015 à 19:01, Dale Henrichs a écrit :



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?

I also use repository descriptions as in Metacello. Here is an example of serialized metadata of a package with cargo:

CGOPackageUnit {
#package : #Grease-Core,
#description : ''Core package of the Grease library.'',
#version : ''1.1.13'',
#timestamp : DateAndTime [ ''2015-04-14T14:51:50.116+00:00'' ],
#dependencies : [ ],
#repositories : [
''http://smalltalkhub.foo/mc/Seaside/Grease11/main/''
],
#file : ''Grease-Core-JohanBrichau.94''
}

I was asking about cross repository dependencies and in this example your #dependencies array is empty ...

What repository does the CGOPackageUnit reside in?

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?

I get metadata on packages at the same central place: the package repository (You could have more that one if needed, e.g. a private package repository).
So you have a completely separate repository of packages....

On a sort of related note ... you are talking about packages here as if they were a complete unit, but my experience with packages is that they are very rarely completely standlone entities ... Most of my projects involve multiple packages that are tightly coupled to each other ... Am I expected to first register each package in the central repository (or private repository) before I can even think of composing a multi-package project ... I assume that I am missing something here ...
In the package metadata, I have the information to get back the source code artifact (repositories and file fields).

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

in the current implementation, there is no distinction between a project dependency (an external dependency) and a package dependency (an internal dependency, i.e. a dependency to a package of the same project).
except that they are presumably specified differently? an example specification would be useful here ...


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

yes

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 understand

  * offer a central place to easily find the package you need (for
    example, java has http://central.sonatype.org/, php has
    https://packagist.org/, etc.)

I am curious about your use of the term "package" here ... is this "package" as in Monticello package,
no
or "package" as in a collection of packages and project dependencies ... or ConfigurationOf or BaselineOf?
package : the unit you want to deliver.
It may be a package unit refering to one Monticello package or a package assembly, i.e. a set of package units and so, a set of Monticello packages.
okay and an assembly of packages looks like?


  * 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?

Yes, I like it but it is not available for Monticello. If we did not have Monticello but git instead, life would be easier.
A BaselineOf can be used with a Monticello repository but it devolves to a #bleedingEdge specification which is a nightmare ...

Life should be easy ...

I guess if your main focus is providing an alternate solution for Monticello repositories then I wish you luck... I don't have the cycles available to try to bridge the gap between Monticello repositories and git repositories ...

I prefer to spend my time making git repositories usable with Smalltalk:)

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.

good to know historical reasons ;)

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

But how do you handle dependencies of projects  using Monticello?

A BaselineOf can specify a dependency on another project and that project may be a BaselineOf or a ConfigurationOf ...

A ConfigurationOf can be serialized to STON just like a BaselineOf ... it will just have a lot more junk it ... junk that is managed by git in a git repository ...

Dale

Reply via email to