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.
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 ...
The components of this virtual package are one or more monticello
packages and a BaselineOf..
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 ...
Dale
