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.