On 10/14/2015 01:00 AM, Christophe Demarey wrote:
Le 12 oct. 2015 à 19:53, Dale Henrichs a écrit :
On 10/12/2015 02:58 AM, Christophe Demarey wrote:
Le 11 oct. 2015 à 22:32, Dale Henrichs a écrit :
When you talk about "virtual packages", I would say that a
BaselineOf is pretty much a "virtual package" already.
I don't think BaselineOf could be seen as a virtual package.
In package A, you tell that A depends on V.
In package B, you simply tell that B provides V. Many other packages
could also provide V.
Then, it is the solver's job to take the most relevant package
providing V.
ah ... I had a different definition of "virtual package" in mind:)
When it comes to cross-platform support there are several factors
that were built into Metacello from the very beginning:
- it should be possible to USE a package on a different platform
than it was
originally written for without modifying the package itself
+1
TBH, it is not yet implement in Cargo because I have a dilemnia:
once you release a version, you should not edit it anymore.
On another hand, you would like to say that this package released
and validated on Pharo 4 is also valid for Pharo5.
A good compromise would be to be able to edit *only *some metadata
of a released package.
This is another reason why I think that embedded package dependency
is a bad idea .... who controls what meta data gets modified and how
do you guarantee integrity.
The same concern applies for non-embedded package dependency. You need
to control who can modify and who cannot. I do not see your point.
As I consider my response I think I am beginning to see where the
difference in our thought processes lie ...
For example my "virtual package" is defined as a specific commit in a
git repository (or any other disk-based SCM) ... the version of the
release is defined as the SHA of the commit, or a tag, or a branch
name ...
in Cargo, I call that an Assembly. It is a set of package units
working together.
The components of this virtual package are one or more monticello
packages and a BaselineOf..
these components in cargo are package units.
One uses the virtual package by cloning the git repository to the
local disk or by using a `github://` description ...
I choose this approach, because in Smalltalk we typically deal with
source code that has to be compiled into our working image ...
I think that with your "virtual package", you are taking the approach
where you are treating the Smalltalk source code as if it were a
pre-compiled entity (like linux packages) and the dependencies
between projects is more difficult to deal with because you have to
worry about the compatibility exeutable binaries ... In the linux
world these binary packages need their own dependency mechanisms
independent of a development environment so indeed there are very
different requirements involved here ... including the need to have
dependency specifications independent of the dependency
specifications used in the development environment ...
If this is closer to the truth, then I will have to say that my
primary concern today is for development time dependencies and the
types of packages that you are talking about with the Cargo Package
Manager are aimed at a completely different problem space altogether ...
BTW, I will read your source code so that I can confirm my
supposition ...
I think we talk about the same packages but with different words.
Virtual packages are just there to allow low-coupling between some
packages. I think this could simplify a lot some project dependency
definition and save time when you need to update it. Maybe for now,
you could just see Cargo managing packages. There package unit and
assembly (composite pattern).
I agree that at this point in time we have to move beyond descriptions
and start looking at source and detailed functionality, because that is
where the differences between Cargo and Metacello will manifest
themselves ... they are both package managers after all:)
Dale