Move from a Hierarchy into a Tree

[0Hughman0]

The alternative, which would be a big re-write would be to somehow make hierarchy not just a list, but something more complex, like a tree e.g.

tree = [
    Home, 
    (DefaultWP, {('1',): WP1, ('2',): WP2}),
    (DefaultSample, {('1', '1'): WP1_1, ('2', '7'): WP1_7}),
    (DefaultDataSet, {('5', '3', '1'): DSet5_3_1})
]

[0Hughman0]

Not clear what the ideal syntax would be.

Using a dict would be a bit tricky, but probably most intuitive.

Would need a symbol for the default.

e.g.

tree = {
    '*': ProjectTreeBranch(DefaultWP, children={
            '*':,
    '

[0Hughman0]

Or:

('*',): WorkPackage,
('*', '*'): Experiment,
('*', '*', '*'): Sample,
('*', '*', '*', '*'): DataSet

[0Hughman0]

Although I don't know how we sort out the name resolution...

Of interest is reflecting, I don't personally use much of the features that are unique to the different 'tiers'.

[0Hughman0]

Project(r'WP(\d).(\d)([^0-9^-][^-]*)-(.+)',
    ('*',): WorkPackage,
    ('1',): WP1,
    ('5',): WP5,
    ('*', '*'): Experiment,
    ('*', '3'): WPX_3,
    ('*', '*', '*'): Sample,
    ('*', '*', '*', '*'): DataSet
)

[0Hughman0]

There's kinda two ways to imagine this.

Either, we imagine we tie things quite closely to the original implementation, with defaults tiers or levels (maybe a clearer name!), and then the user can occasionally provide customisations, perhaps by editing their cas_project.py. A problem with this approach is we run into the mental block of... well this aspect of the project has no samples... so why is it called samples?

Another idea is that we make things super flexible, somehow, every type in the tree structure has to be specified, perhaps via the UI (which sounds like a bit of a nightmare). This would probably require moving the configuration of this tree to a separate file e.g. a json somehow... this does kinda take a step closer to the idea that Cassini could simply be an API spec...

This file could be managed by Cassini somehow.

However, I like the way Cassini is configured via the cas_project.py file., especially as we expect users are mostly python native scientists.

Another issue with the later approach is it's unlikely a user knows in advance what their tree will look like. Hence the need for the UI to be used to customise it.

[0Hughman0]

It takes a step closer to having a database. Which is maybe actually what we need. But I am nervous of, because it stops any multiple instances of Cassini running, which is already dodgy, but does kinda work.

[0Hughman0]

Another idea is that users could write a Python file that lives in the directory that handles customisation?...

So basically when project['WP1.1a'] is called, it checks for this file and wraps the resulting object in some way...?

[0Hughman0]

Cassini/cassini/core.py

Line 905 in ab613e3

def get_tier(self, identifiers: Tuple[str, ...]) -> TierABC:

could do this.