New name for pyFAST

[ebranlard]

(see #38)
Unfortunately the name pyFAST is already taken: https://pypi.org/project/pyFAST/
People attempting to install it by doing pip install pyFAST will end up with the wrong repository.
Also, on the main page of our github repository, on the right panel, the box "Used By" will show repository that use the other pyFAST.
I'm therefore suggesting to rename the package.
Here are some options below, thank you for your vote!
NOTE: pyf and pyFAST are not available on pypi

Some line of thoughts:

• A name easier to pronounce can be nicer
• A name long to type can be frustrating.
• Change of case might be unconventional

for now, the options below are case insensitive (just to limit the number of options)

[andrew-platt]

what about pyOpenFAST?

[ebranlard]

thanks, I've added the option

[rafmudaf]

I read pyOpenFAST or another other iteration of a similar name as a Python version of OpenFAST. As in, something where I could run an OpenFAST simulation directly through Python. While I think the argument could be made that this is true of this repository, I understand this to be primarily related to pre and post processing.

[rafmudaf]

I like that this repo name has included some indication that it is a set of tools for dealing with all the things before and after running an OpenFAST simulation. So for my vote, something along the lines of "toolbox" in the name would be explicit for users.

[rafmudaf]

pip install openfast-tools reads nicely, in my opinion.

[rafmudaf]

@ebranlard are you planning to keep the name pyFAST for the internal modules?
Also, do you think the Python interfaces currently in kept in OpenFAST have a place in this repository? I'm referring to things like openfast_library.py, moordyn_library.py, aerodyn_inflow_library.py, and hydrodyn_library.py. FWIW I'm not sure whether they belong here, but I've always thought it would be nice to have those be pip-installable as well. I suppose that could be accomplished from the OpenFAST repo, but it would be more complex.

[ebranlard]

I would think it's nicer if the repository name, the pypi python package and the module name are the same, no? I like openfast-tools but the hyphen is not ideal in this case. I was indeed thinking of replacing all the pyFAST by openfast_tools if it's what we agree on. So it would be from openfast_tools.elastodyn import * or import openfast_tools as oft. Are you thinking we should keep pyFAST ? Then we should likely rename this github repository, otherwise we'll have three different names :)

I think it could make sense to have the python wrapper live here, but I would prefer if the compilation remains out of this repository. We can find the dlls based on some environmental variable / explicit setting from the user.

[rafmudaf]

It's a good point about the -, that's a no-go. I agree that it would be best if the repo, pypi target, and top-level module are the same name. For something like the Python interfaces to OpenFAST, this could be one submodule within the overall project. For example, if the project is structured like this tree:

openfast_tools <or this repo's name>
├── __init__.py
├── aeroacoustic
├── airfoils
├── case_generation
├── converters
├── fastfarm
├── input_output
├── linearization
├── pyFAST
│   ├── __init__.py
│   ├── aerodyn_inflow_library.py
│   ├── hydrodyn_library.py
│   ├── moordyn_library.py
│   └── openfast_library.py
├── postpro
└── tools

Then the interfaces could be used something like this:

from openfast_tools import pyFAST
moordynlib = pyFAST.moordyn_library()
moordynlib.init()

from openfast_tools.pyFAST import moordyn_library
moordynlib = moordyn_library()
moordynlib.init()

On the OpenFAST binaries, I agree that it would be out of scope to compile it under this project's infrastructure. OpenFAST is not currently distributed through pypi, but it could be. In that case, a dependency of this repo could be OpenFAST. If you don't want for all users to have to install OpenFAST, you can configure this project with Extras so that you have to opt-in to get the OpenFAST target as well; something like pip install openfast_tools[openfast]. OpenFAST is already available through conda.

[ebranlard]

That makes sense I like it.

[ebranlard]

pyFAST has been renamed to openfast_toolbox and migrated here: https://github.com/OpenFAST/openfast_toolbox