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