Most projects that I'm aware of, follow something like this:

- 1 project per git repository

- One or more packages for the functional part, separate packages for the tests (because if you only use categories you can't load only the runtime required code and exclude the tests)

- If your project has optional parts, and this code is in different packages you can provide in the Baseline "groups" for loading sub-sets of the packages 

Usually, we use https://github.com/ba-st/GitHub-setup for generating the initial boilerplate of new projects.

Regards,

Gabriel

On Wed, Apr 19, 2023 at 12:55���PM Steffen M��rcker <merkste@web.de> wrote:

Hi,

I'd like to ask for your advice or best practices regarding the package

structure of a project. So far I have understood:

- Iceberg can store multiple packages (project?) in a git repository

- A package (or multiple?) and its dependencies is loaded via a baseline

- A package can have flags (= categories?)

Suppose, a project has

- A core part

- One or multipel optional parts, that a user may or may not want to load,

too

- Tests for the core

- Tests for each optional part

What's the recommended way to structure this in Pharo? For example, I've

seen that some code in Pharo has its tests in the same package but

flagged/categorized, other code has a separate package for tests. Also, can

a (git) repository have multiple baselines?

Sorry, if I am asking the obvious but I did not manage to find guidlines in

the documentation yet. It might very well an oversight be myself.

Kind regards,

Steffen