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