Shorter import statements

[wigging]

WaterTAP has long import statements for getting modules and functions from the package. For example, the statement for importing the ReverseOsmosis0D model is

from watertap.unit_models.reverse_osmosis_0D import ReverseOsmosis0D
ro = ReverseOsmosis0D()

I suspect this is a bad habit taken from IDAES which has import statements such as:

import idaes.models.properties.modular_properties.pure.Perrys as Perrys

Is there a reason why relative imports can't be used in the watertap package to make these imports more concise? Such an implementation would allow a single statement to be used for importing watertap features as shown below.

import watertap as wt
ro = wt.ReverseOsmosis0D()

Using a single import would eliminate the need for multiple imports.

# Current watertap implementation

from watertap.property_models.NaCl_prop_pack import NaClParameterBlock
from watertap.unit_models.reverse_osmosis_0D import ReverseOsmosis0D
from watertap.unit_models.reverse_osmosis_0D import ConcentrationPolarizationType
from watertap.unit_models.reverse_osmosis_0D import MassTransferCoefficient

properties = NaClParameterBlock()
unit = ReverseOsmosis0D(
    property_package=properties,
    concentration_polarization_type=ConcentrationPolarizationType.none,
    mass_transfer_coefficient=MassTransferCoefficient.none,
    has_pressure_change=False)

# Suggested implementation

import watertap as wt

properties = wt.NaClParameterBlock()
unit = wt.ReverseOsmosis0D(
    property_package=properties,
    concentration_polarization_type=wt.ConcentrationPolarizationType.none,
    mass_transfer_coefficient=wt.MassTransferCoefficient.none,
    has_pressure_change=False)

[bknueven]

We have some of this, see, e.g., https://github.com/watertap-org/watertap/blob/main/watertap/unit_models/__init__.py.
So you can do:

from watertap.unit_models import ReverseOsmosis0D

We should probably do something similar for the property models. The MassTransferCoefficient and ConcentrationPolarizationType probably don't need to be imported at all if they're StrEnums (and if they're not, that's what they should become).

That said, I'm not sure how much we should put in the top-level. I think it's useful to have unit models and property packages in different places, for example.

[wigging]

Not everything has to be accessed from the top level. You can still do any of the following with the proper __init__.py implementation:

# Approach 1

import watertap as wt
unit = wt.ReverseOsmosis0D()

# Approach 2

import watertap as wt
unit = wt.unit_models.ReverseOsmosis0D()

# Approach 3

from watertap.unit_models import ReverseOsmosis0D
unit = wt.ReverseOsmosis0D()

[lbianchi-lbl]

I don't think I have enough experience with the WaterTAP API to have an informed opinion on the pros and cons of the ergonomics/DX aspects of this, but I thought I should mention that in WaterTAP, because of the IDAES API, there's a significant amount of import-time side effects.

For many reasons, I personally think this is in abstract not ideal (e.g. I suspect is also the reason why the pytest collection phase takes several seconds), but practically speaking, getting rid of this would most likely be a huge undertaking across the entire IDAES ecosystem.

So, the situation being what it is, pulling too many sub-packages into the top-level watertap package could result in similarly long import times when importing any package. I guess one could do the reverse, i.e. each subpackage "registers" (a subset of) its contents on the top-level module (not sure if this what you meant with Approach 3?):

# in watertap/unit_models.py
from .reverse_osmosis import ReverseOsmosis0D

import watertap
for obj in [ReverseOsmosis0D]:
    setattr(watertap, obj.__name__, obj)
del watertap

but I'm not sure if (A) this would work reliably, and (B) the payoff would be worth the added magic-ness (for one, it would probably stump static analyzers such as pylint).