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