Various user files changes

[krzywon]

Description

This changes a number of items related to user files:

• All functions and constant PATHs were moved into sas.system.user so they are all in one location.
• On launch, example data files are copied from the installed/active directory into the OS-desired
• On launch, an attempt is made to move all files from the installed location to the desired user location. Nothing is written if the file already exists in the resulting path.

Refs #3522, #3485, #3201, #3062 - This PR may fix a few of these, but more testing is needed for each.

NOTE: The example data location still needs to be updated in other parts of the documentation.

Review Checklist:

Documentation (check at least one)

• There is nothing that needs documenting
• Documentation changes are in this PR
• There is an issue open for the documentation (link?)

Installers

• There is a chance this will affect the installers, if so
  • Windows installer (GH artifact) has been tested (installed and worked)
  • MacOSX installer (GH artifact) has been tested (installed and worked)
  • Wheels installer (GH artifact) has been tested (installed and worked)

Licensing (untick if necessary)

• The introduced changes comply with SasView license (BSD 3-Clause)

[rozyczko]

Minor comments on the methods copied around. I know these were just copied, not written in this PR, but I made some suggestions anyway.
The rest looks OK.

src/sas/sascalc/system/user.py fails ruff with a minor issue. Please consider fixing.

[rozyczko]

You might want to wrap this in an exception handler to catch things like permission issues

[llimeht]

Note sure about this. There is exception handling in the caller - any exceptions thrown means "sorry, no docs for you" gets logged and the UI handles that. Handling the exception here means a pathway to pass the exception back to the user is needed.

[rozyczko]

It would probably be safer to elif this branch and use else to throw or at least send some info to warn the user that source_dir and build_dit can't be found.

[krzywon]

This is only defining the likely locations for the documentation files. A check is performed later if either location does not exist.

[llimeht]

Thanks for some tidy-up and documentation @krzywon!

I'm not sure whether this is part of a series of PRs that is planned or if this is and end-point of this work - the items below might be a todo list for the next PR.

• I understand that doc-regen is off the table — there is no need to copy doc source and doc build to ~ any more. All of this can be simplified to "where is the html file on disk" (for the vast majority of users for whom it will be unpacked on disk; for a couple of exotic use cases, it could be popped into a tempdir)
• is copying the example_data to ~ a desirable thing? It's not like ~/AppData is an easily findable location on Windows (I'm curious whether that path is actually different under different types of Windows installation too)
• The commit message and code says "move" ("Move example_data into user") but it's actually copying not moving
• The doc for Example Data says the docs are moved at install time but they are actually copied at runtime.
• The docs for the example data point to example_data_help but sasdata/example_data/media/testdata_help.rst is the actual documentation - that probably should just get fixed at the sasdata end though.

[krzywon]

@llimeht, thanks for the documentation catch and simplification suggestion. I'll fix those shortly.

I'm not sure whether this is part of a series of PRs that is planned or if this is and end-point of this work - the items below might be a todo list for the next PR.

It is meant to be the first of about 5 PRs as I see them, in the possible order I envision them:

1. Create a lightweight way to generate the documentation from plugin models, using pydoc, rst2html, or another similar package. I will remove sphinx from the dependencies list at this point or in PR2.
2. Remove doc generation routines that aren't used in plugin model generation. (could be combined with 1)
3. Disable documentation moves and use the methods that find the installed locations rather than the user location. This will likely include an additional check to find the documentation on sasview.org based on the version.
4. Ensure plugin models that exist in ~/.sasview/plugin_models are destroyed once they are in ~/<new_location>. Currently, if you delete a plugin through the model manager that was in the original location, it is moved back into the new location on next application launch.
5. Add methods to open the user folders through the GUI. The only OS that reliably allows this is Windows, so it might be limited, which is why I have it lower priority.

[krzywon]

is copying the example_data to ~ a desirable thing? It's not like ~/AppData is an easily findable location on Windows (I'm curious whether that path is actually different under different types of Windows installation too)

From a MacOS perspective, absolutely. It's very difficult to find the example data (#3201). For other OSes, it's debatable.

[jamescrake-merani]

Approving this, as I think the changes here are reasonable.

[krzywon]

Once the CI completes, I plan to merge this