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