Hi

> On 20. Feb 2022, at 12:16, Jörg Belger <unique75 at web.de> wrote:
> 
> I tried the feature in Monticello in the context menu of a package „Add Required Package“. This sounds to me like adding a prerequisite. But it loads always the latest version of that prerequisite, it does not ask to select a version. Maybe there is a setting for that, I don’t know. But the feature looks rudimentary, because there is np possibility to see a list of all required packages, except you inspect the working copy of package.
> 

"Add Required Package" is virtually unused.
I saw it last used for a specific package set around 2009.
And even then I was surprised.

Best regards
  -Tobias

> Your description is very detailed, but I think it sounds all to me very over-complicated. if a tool restricts you in your thinking or is´nt simple enough, then maybe you should rather use another tool.
> 
> Jörg
> 
>> Am 20.02.2022 um 01:12 schrieb Jakob Reschke <jakres+squeak at gmail.com>:
>> 
>> Comparing with the status quo:
>> 
>> Am Sa., 19. Feb. 2022 um 21:04 Uhr schrieb Jörg Belger <unique75 at web.de>:
>>> 
>>> You can always publish/commit the „App-Bundle“ and both sub-packages are committed [...]
>> 
>> Monticello does not offer such convenience as far as I know.
>> The Git Browser does this when committing a project, and you can
>> choose to only commit the changes to a single package even if you
>> track more. But it does not assign version ids to the packages, it
>> just saves what it is told to save in the new commit.
>> 
>>> 
>>> But others can also load the single package „App-Tests-Package“ and the prerequisite „App-Implementation-Package“ is automatically loaded [...]
>> 
>> If I read the code correctly, Monticello package dependencies (which I
>> have not seen being used by anyone so far) could accomplish the same,
>> *but* not without doing some manual setup beforehand:
>> 
>>> 
>>>       App-Bundle
>>>               App-Implementation-Package
>>>               App-Tests-Package
>>>               Tools-Package
>> 
>> In the example, with a clean image you would need to
>> - open the Monticello Browser
>> - add the Monticello repository that contains this bundle and its packages
>> - add an App-Implementation-Package (as if you wanted to start
>> developing one from scratch)
>> - add the repository to that package
>> - then open that repository and load App-Tests-Package.
>> 
>> Then it would also resolve and load App-Implementation-Package
>> automatically if App-Tests-Package was saved with a dependency on
>> App-Implementation-Package.
>> 
>> So you have to do half of the dependency resolution manually for this
>> to work "automatically" afterwards.
>> 
>>> 
>>> What is when others want your „Tools-Package“ coz it contains really useful things. Then this is located only in your „project“ repository and you need to extract it, so that others can integrate it in their app or in their bundle respectively.
>> 
>> In both Monticello and Git there is no notion of a central repository
>> shared by everyone participating in the ecosystem, hence one cannot
>> assume that others will have their packages and bundle-equivalents in
>> the same repository as the App-Bundle and Tools-Package. The three
>> solutions (which I know of) to this scattering are: copy the package,
>> Monticello configurations and Metacello.
>> 
>> In Monticello there is a Copy button to copy a single version of a
>> package (or configuration) to another repository. To copy it to a Git
>> repository you could save the loaded package to that repository with
>> the Git Browser (which would not preserve the history of the package)
>> or you would need to convert the Monticello package history to a Git
>> history, which results in a branch that you could merge into your main
>> branch... Obviously in either case you have to take care of updating
>> the copied package yourself in your own repository, there is no trail
>> back to the original repository and any newer versions there.
>> 
>> A Monticello configuration is a list of package versions plus a list
>> of repositories. When you load the configuration it will try to find
>> the listed versions in the listed repositories and load these
>> versions. The configuration is itself stored like a package in a
>> repository, so until here it looks similar to a bundle. But when you
>> save a configuration it does not create new versions of the packages
>> if they are modified – it just warns you about it. Moreover when a
>> configuration is read from a repository, all repositories listed in
>> the configuration that the image does not know already are assumed to
>> be MCHttpRepositores. So unfortunately in a clean image it would not
>> work to refer to GitHub repositories from Monticello configurations as
>> of now.
>> 
>> Metacello configurations are these ConfigurationOfXyz classes, which
>> specify (among other things) a list of packages, dependency packages,
>> and links to other configurations, and for each of them from which
>> repository to obtain them. With links to other configurations,
>> Metacello is able to resolve transitive dependencies, which Monticello
>> configurations cannot do. At least I did not find a way to nest
>> Monticello configurations (i. e. refer to another one by name). But if
>> you refer to Monticello package versions directly from a Metacello
>> configuration, the transitive dependencies will not be detected
>> either, unless the configuration specifies them explicitly. (Or the
>> Monticello package dependencies feature was used and you did the
>> manual upfront work as described in the beginning...) Since Metacello
>> is not integrated with the Monticello tools (or the regular Smalltalk
>> tools), creating new configurations for Metacello also does not create
>> new versions of packages automatically.
>> 
>> Squeak projects on GitHub mostly rely on Metacello. In the case of
>> GitHub (or Bitbucket) repositories, the string that tells Metacello
>> the repository contains the branch name, tag name, or commit hash.
>> Metacello then loads a so-called baseline, which is like a
>> configuration, but lacks version numbers for the "local" packages
>> because it will just use what the downloaded commit contains. It might
>> also work to load just a single package instead of a whole baseline. I
>> believe I have not tried that yet. That would allow you to load
>> Tools-Package from another GitHub repository, giving a branch, tag or
>> commit to specify which version you want (so you give the project's
>> version, which implies an unnamed version of the package).
>> 
>> Even if it is not possible to specify single packages, it will still
>> be possible to have multiple groups of packages in the baseline and
>> load only a specific group. For Tools-Package it would mean to ask the
>> maintainer of App-Bundle to add a group that contains only
>> Tools-Package, then depend on this group in your own baseline. For
>> example, the baseline for the repository which contains the Git
>> Browser has a group just for the package with the Git implementation,
>> so that can be loaded on its own:
>> https://github.com/hpi-swa/Squot/blob/v0.9.0/src/BaselineOfSquot.package/BaselineOfSquot.class/instance/baseline..st#L50
>> 
>> Everything that makes up the core of Squeak is in the Trunk Monticello
>> repository. It does not require packages from other repositories.
>> On the other hand the Trunk repository is not supposed to contain
>> extra packages, like Metacello, not maintained by the core Squeak
>> developers.
>> 
> 
>