Migrate to 'src' Project Layout

[jorgepiloto]

📝 Discussion

Multiple projects inside pyfluent
At the moment, all source files are located inside the ansys/ directory, which is contained at the root of the project. This folder holds:

• The ansys-fluent-core libary.
• The ansys-fluent-parametric library.
• The ansys-fluent-post library.
• The ansys-api files, which are generated from the logic under codegen and protos directories.

I saw that pymapdl follows the src/ layout exposed in the dev-guide. This is accomplished by having an ansys-api-mapdl in the Ansys GitHub organization.

I do not know which is the reason for not having an ansys-api-fluent repo in the Ansys organization. Is it because this product is still private?

Library layout
The current layout means having three separate libraries inside the ansys/fluent directory, as there is no __init__.py file:

ansys/fluent
├── core/
├── parametric/
└── post/

Ideally, each one of these libraries should be maintained in its own repo while having its own setup.py file. However, to reduce maintenance tasks, some advantage is taken from the find_namespace_packages() function in the setup.py file.

Although all three libraries are installed with the ansys-fluent-solver name, it is possible to run:

from ansys.fluent import core, parametric, post

However, the following is not permitted:

for pkg in [parametric, post]: print(f"{pkg.__version__ = }")

This is because parametric and post lack of a __version__ attribute. To keep using a single-source defined version, the following may be applied:

# Add this line to parametric/__init__.py and post/__init__.py files
__version__ == ansys.fluent.core.__version__

Moving to a src/ layout
This could be done by adding find_namespace_packages(where="src", include="ansys*"), which would still lead to:

import ansys.api.fluent.v0
from ansys.fluent import core, parametric, post

[RobPasMue]

Maybe it is a good opportunity to tackle #109 as well @dnwillia-work, since it will already require moving around the structure of the repository.

[seanpearsonuk]

@jorgepiloto @RobPasMue @dnwillia-work @mkundu1

I do not know which is the reason for not having an ansys-api-fluent repo in the Ansys organization. Is it because this product is still private?

I believe that that is the case.

Moving to a src/ layout

I am not against this if it leads to greater conformity. It also provides clearer organisation.

[seanpearsonuk]

Maybe it is a good opportunity to tackle #109 as well @dnwillia-work, since it will already require moving around the structure of the repository.

@jorgepiloto is it practical for you to tackle #109 as part of this?

[jorgepiloto]

Thanks for the comments, @seanpearsonuk @RobPasMue. I think it's feasible to combine both tasks into a single one. Letting @RobPasMue to address this 🚀

[seanpearsonuk]

I have discussed this with @mkundu1:
In this release we should:

• introduce the src folder
• address the issue of public/private modules and packages (Internal vs. Public API #109). Perhaps this should be addressed by the core Fluent team, who know the use cases?

In the next release we should:

• split into multiple repos

[dnwillia-work]

@RobPasMue @jorgepiloto The only reason we've not implemented the 'src' reorganization is time/priorities. These things tend to get decided on us but there is no coordinated planning to transition all the repos so we have to plan for it when we get time.

There are other inconsistencies as well, eg: the template was updated to use flit instead of setuptools but we've not done that yet either.

I'm fine with the proposed reorg.

[dnwillia-work]

I renamed this issue to only address the 'src' layout reformatting part of the issue. Splitting up into multiple repos is covered by #305

[RobPasMue]

I renamed this issue to only address the 'src' layout reformatting part of the issue. Splitting up into multiple repos is covered by #301.

Got it, thank you @dnwillia-work!

[RobPasMue]

I renamed this issue to only address the 'src' layout reformatting part of the issue. Splitting up into multiple repos is covered by #301.

By the way, did you mean #301 or #305? #301 is a recently closed PR

[dnwillia-work]

I renamed this issue to only address the 'src' layout reformatting part of the issue. Splitting up into multiple repos is covered by #301.

By the way, did you mean #301 or #305? #301 is a recently closed PR

Thanks. A typo, I meant 305.

[RobPasMue]

Just to let you all know @dnwillia-work @seanpearsonuk @mkundu1 @jorgepiloto

When implementing this migration, bare in mind that it will for sure cause conflicts throughout all open pull requests / branches. Specially if they involve creating new files. All branches should be updated (i.e. merged with main) when this PR is closed to avoid problems.