poly info command does not list components under lower level namespaces

[hugobettmach]

Is your feature request related to a problem? Please describe.
Hi @DavidVujic, first of all this is such a great project, this way of organising python code makes so much sense in many situations.

The issue I came across is related to using multiple namespaces, under the top level namespace (or org_name) as mentioned in #45. This is something I think could be very useful for my use case.

But, when creating something like the example below...

├── README.md
├── bases
├── components
│   └── org_name
│       ├── namespace_1
│       │   ├── component_1
│       │   │   ├── __init__.py
│       │   │   └── core.py
│       │   ├── component_2
│       │   │   ├── __init__.py
│       │   │   └── core.py
│       │   └── component_3
│       │       ├── __init__.py
│       │       └── core.py
│       └── namespace_2
│           ├── component_1
│           │   ├── __init__.py
│           │   └── core.py
│           └── component_2
│               ├── __init__.py
│               └── core.py
├── development
├── poetry.lock
├── projects
├── pyproject.toml

Using poetry poly create component --name=namespace_1/component_1... And then running poetry poly info, I get:

Workspace summary

projects: 0
components: 2
bases: 0
development: 1

  brick                                                                       development
 ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  namespace_1                                                                      -
  namespace_2                                                                      -

Describe the solution you'd like
Would be nice poly info could list all the components detected under "sub namespaces". Same would apply to bases as well. For example, would like a summary something like the one below. Hopefully this makes sense?

Workspace summary

projects: 0
components: 5
bases: 0
development: 1

  brick                                                                       development
 ────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
  namespace_1                                                                      -
      component_1                                                                  -
      component_2                                                                  -
      component_3                                                                  -
  namespace_2                                                                      -
      component_1                                                                  -
      component_2                                                                  -

Additional context
Following on #45.

[DavidVujic]

Thank you, very interesting ideas @hugobettmach! Today the namespace_1 and namespace_2 are categorized as components by the poly tool, but I think it makes sense to support this kind of scenario too.

[DavidVujic]

This could possibly be a new theme. Identifying bricks using a structure like <top-namespace>/<sub-namespace>/<brick>.

How are the bricks included in the pyproject.toml files?

[hugobettmach]

For now we are just testing the new setup so we follow your recommendation:
{include = "<top-namespace>/<sub-namespace>/<brick>", from = "../../components"}

But could also be nice to have some thing like include all bricks from a sub-namespace, e.g.:
{include = "<top-namespace>/<sub-namespace>/*", from = "../../components"}

[DavidVujic]

Thanks! I think that you can use the * wildcard already, if I'm not mistaking it will run the app properly (but the Polylith tooling will probably not recognize the usage).

Edit, similar discussion here: #89 (comment)

[DavidVujic]

I'm going to give the theming a try, but I would recommend you to reconsider the sub-namespacing into a flat structure as suggested in the loose theme style. All bricks should probably be on the same level if you want to go all-in Polylith.

If you still want the sub-namespacing, with the current tooling (while waiting for a future version to support it), you could do something like this: put all your bricks in the bases and components folder, without a sub-namespace. Then create a new component, named after your sub-namespace.

Example:

create a new "component" (i.e. your sub-namespace):

poetry poly create component --name my_namespace_1

Import the bricks that should belong to this sub-namespace in the __init__.py of the "component" my_namespace_1:

#  the __init__.py file
from org_name import component1, component2

__all__ = ["component1", "component2"]

When using the bricks in a sub-namespace, you could import it like this:

#  some other module using the bricks in a sub-namespace
from org_name.my_namespace_1 import component1

...

The pyproject.toml would need to add all components needed + the new namespace:

packages = [
    {include = "org_name/component1", from = "components"},
    {include = "org_name/component2", from = "components"},
    {include = "org_name/my_namespace_1", from = "components"},
   ...
]

[DavidVujic]

I understand that you might want bricks with the same name, but in different in sub-namespaces. This could be accomplished in the suggestion above, but with an alias:

#  the __init__.py file of namespace_1
from org_name import some_brick_doing_X as component1
from org_name import some_brick_doing_Y as component2

__all__ = ["component1", "component2"]

#  the __init__.py file of namespace_2
from org_name import some_other_brick_doing_X as component1
from org_name import some_other_brick_doing_Y as component2

__all__ = ["component1", "component2"]

When importing the namespace, it expose the alias:

# import the component via the namespace, that has been "renamed" (alias)
from org_name.namespace_1 import component1

[hugobettmach]

Thanks @DavidVujic for your suggestions. This may be all we need :)

[lhttjdr]

Thank you for your excellent work.

Although using alias is a good workaround, is there a plan to support namespace in future?

[DavidVujic]

Hi @lhttjdr! Currently, I'm not focusing on that part. The general recommendation for Polylith is to have a fairly flat structure: a shared top namespace, and one sub-namespace (that itself can have any number of sub-namespaces/folders). The combination of a top namespace and the upper most sub-namespace becomes a brick, top_ns/brick.

You can have it namespaced with several sub-namespaces, but Polylith will only recognize the upper most one as a brick. From a functionality aspect it shouldn't be any issues with it.