-
Notifications
You must be signed in to change notification settings - Fork 56
Description
Looking through the code today, and a few of the other pansys modules, I think it would be good if we organized things so it's clear what modules/packages contain external public APIs and what are implementation. For instance, see the image below. Everything with a red line looks public to me, everything with green line is hidden (but we want to make it public soon) and everything with a blue line is implementation.
I'm not sure about the best way to organize it, but I think we should try and do something a bit different here. Would it make sense to follow a convention to separate packages into private and public like you can do in the modules. eg:
ansys/fluent/_impl1 # Implementation package 1
ansys/fluent/_impl2 # Implementation package 2
ansys/fluent/api1 # Public API package 1
ansys/fluent/api1/moduleA.py # Public module A in api1
ansys/fluent/api1/_moduleB.py # Private module B in package api1
ansys/fluent/api2 # Public API package 2
ansys/fluent/api2/moduleA.py # Public module A in api2
and so on. The documentation builds can then be configured to only look at the public packages and public modules within those packages, testing only needs to be created for the public APIs etc..
There are packages such as codegen as well. This module needs some documentation but it's more of a utility thing, maybe we could rename the area to 'utilities' and not package it with the wheel or something.
