Standardize on example URLs across package documentation

[Andy-Grigg]

Most of the packages within PyAnsys refer to remote resources using URLs. We should standardize how we refer to example server locations in docs:

• http vs https
• example.com vs localhost vs my_server_name

[da1910]

I would strongly support https wherever possible, I think it should be a noted exception if a method or class does not support secure connections.

Regarding URLs I would slightly prefer something that's unlikely to accidentally work, example.com always returns 200, which would be nice for some cases and less helpful in others.

[Andy-Grigg]

I would strongly support https wherever possible, I think it should be a noted exception if a method or class does not support secure connections.

Something to consider with https is that certifi (used by requests) generally doesn't work by default with enterprise CAs. We should take care to document how to work around this limitation, I know python-certifi-win32 is a good option for Windows, not sure about options on Linux or other platforms.

[da1910]

This is true, whilst we are stuck with requests we're very unlikely to be able to completely avoid this problem. That said, I still think we should be advocating strongly for secure authentication and transport wherever possible.

As you say the easy fix for windows is that package, there isn't an equivalent for *nix systems, since the location will vary depending on how you have openSSL, and whether you've built it yourself or are using a packaged version. This is not a problem that has an easy solution, see discussions here and here for some context.

In the interrim I think as long as we make it clear for each package how custom certificates may be loaded, we shouldn't overly inconvenience users. If a user decides to connect to an insecure http:// url then there's not much we can do. We probably should stop them from using Basic auth in this case, but in the end we're a library and if users want to advertise their credentials to all and sundry there's not much more we can do.

[RobPasMue]

Hi @Andy-Grigg @da1910 - as you may already know, this repository is starting to serve the purpose of a "metapackage" (i.e. containing the different PyAnsys packages compatible with a certain Ansys version (221, 222, 231...). I am doing some cleanup on the repo and just came across this issue.

I have some questions:

• Is this still an issue? I think I may not fully understand what's the purpose of this issue. Though I agree that there should be some standard way of referring to example servers throughout the docs, this depends on each library alone. We can provide recommendations but not force all libraries to use the same pattern.
• If this is no longer an issue, or has low priority, can we close it?

I will be closing automatically the issue if by August 26th I do not get a response. Thanks in advance!

[Andy-Grigg]

Hi @RobPasMue . Happy to close this. It was as you said in your first bullet point, just trying to ensure that we think about a consistent approach to referring to example servers when it comes to documentation.

I think it's still an issue that we should aim to reach a consensus on, but I'm happy for it to be closed if needed.

[RobPasMue]

Yes, I think it is outside the scope of this repository from now onwards. But it is definitely something to take into account. I am transferring it to the dev-guide repository, in which we are providing guidelines for all PyAnsys repositories! I think it is the most appropriate location at this point =)