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).
smime.p7s
Description: S/MIME cryptographic signature
