Whether you're installing SasView to use as a tool for your research or
because you're wanting to work on the code, it is recommended that you
work inside a Python virtual environment of some sort.
A venv or a conda are both popular choices.
Installers for SasView can be found at https://www.sasview.org/, for various operating systems. You will also find walk through tutorials on how to install and use SasView. Note that SasView requires Python 3.12+.
You can also install SasView using standard Python installation tools, such as
uv tool install sasview(orpipx install sasview) to install it into its own standalone environment- or
uv pip install sasview(orpip install sasview) to install it into your current Python environment.
If you're familiar with working with developing in Python, then the very quick version is:
# clone the repository
git clone https://github.com/sasview/sasdata/
git clone https://github.com/sasview/sasmodels/
git clone https://github.com/sasview/sasview/
cd sasview
# create the virtual environment
python -m venv .venv
# .venv\Scripts\activate & REM Windows: activate environment
. .venv/bin/activate # Linux/Mac: activate environment
# install repositories in editable/developer mode in the venv
# use "python -m ..." to ensure the venv's pip is used
python -m pip install -e ../sasdata
python -m pip install -e ../sasmodels
python -m pip install -e .[dev,test]
# test if sasview launches
python -m sasStep by step, that is:
- Obtain the SasView source using
git. You will likely need to coordinate updates tosasdataandsasmodels. Thebumpsandperiodictablepackages are far more loosely coupled, but depending on what you are doing you may also want them as development packages. - Create a Python virtual environment in the
.venvdirectory. - Activate the
.venvso that Python and its modules from the venv are used. Note that the particular syntax above works for thebashandzshshells under Linux, Windows and macOS; if you usecmdor PowerShell under windows, there are different ways to activate the virtual environment. - Install the necessary modules for building and running SasView, including the documentation and GUI.
It will take a while to download and unpack all the dependencies.
The
pip install -ecommand says to install the package in development mode so that any changes you make in the source tree will be available the next time you run the program. We execute this using thepython -msyntax in order to ensure that the virtual environment python is used. The.[dev,test]syntax says to install the current directory (sasview) with test and dev dependencies. - Run SasView! As an alternative to typing
python -m sas, you can simply typesasview.
Almost all the modules that SasView needs are available as precompiled modules on PyPI, including numpy, scipy, h5py, pyside6. A handful of Python-only modules will be built into wheels on your local machine. Installing the dependencies should be a one-off task.
When you want to work on SasView again at a later date, you can type:
# .venv\Scripts\activate & REM Windows: activate environment
. .venv/bin/activate # Linux/Mac: activate environment
python -m sas(or the equivalent command for your shell to activate the venv)
Note that many Python-focused integrated development environment programs have the ability to activate the venv for you as part of the process of starting and debugging software, e.g.:
The SasView, SasData and SasModels repositories include pre-commit hooks, which can be set up to enable linting to be run on the code. A linter is a tool that can detect programming errors, bugs, stylistic errors, etc. SasView uses the Ruff package for linting. Ruff is able to warn about a wide range of possible errors, and in some cases apply automatic fixes for them.
When code is submitted to the SasView repository, we make sure to always apply all available automatic fixes for any linting violations present. The pre-commit hooks can be used to warn of any linting errors when committing to the local branch, or pushing that branch to the repository.
To use the pre-commit hooks provided in SasView, first activate your virtual environment and install the pre-commit package with:
pip install pre-commitTo set up the pre-commit hook for a package, simply navigate to the appropriate directory for the package and type:
pre-commit installThis will configure the pre-commit hook for the relevant package.
Important
To set up the pre-commit hooks for SasView, SasData, and SasModels this command needs to be run in the directory for each package separately.
Having set up the venv for your work, it's important that you activate the venv and run sasview inside it. When you're working across several different sets of changes, you might end up with multiple different venvs.
The instructions above used editable installs (that is -e for pip) which means that any changes to Python code and resources that live inside the Python module next to Python files (like icons) will take effect from when you next start SasView. This will be true for all the projects that you installed as editable installs in setting up your development environment.
For files that do not live in git in the same place as the module expects to find them, the magic of editable installs does not work, likewise for files that are generated as part of the build process.
GUI — automated: For .ui files that are part of the SasView GUI, new Python files are automatically regenerated by sasview if needed so there's nothing manual you need to do.
Running uic to make the user interface is fast enough that it can be done on the fly so we can get away with this.
Documentation and other resources — manual steps required: running sphinx is not fast, and so Python will need some help from you for the documentation and some other files that do not live in git in the same place as they do in the installed Python module. Specifically editable install magic does not apply to:
-
files that are listed in
pyproject.tomlin theforce-includesblocks:example_datasrc/sas/sasview/media/
-
all sphinx documentation files; the source for the documentation is assembled by
collect_sphinx_sources.pyfrom files scattered across multiple projects. The documentation is then built by sphinx and the output needs to be installed. In particular, the following need manual handling in the editable installation:.rstfiles- auto-generated documentation files from apidoc
- auto-generated model descriptions and sample output
- images that are copied into the documentation (often from
mediadirectories in the case of SasView)
To have changes to any of these file propagate into the build, the module needs to be reinstalled: python -m pip install -e .
The process of reinstalling the module rebuilds the documentation and copies it into site-packages, so that it can be used. Since all the dependencies are already installed, the build just runs the sphinx tools with the correct options and copies the output.
To be explicit:
-
sasmodels: you change model files or documentation in
sasmodels-
if you just want to see what that looks like to check your syntax etc, then
- inside your sasmodels directory:
python -m pip install --no-build-isolation -e . - look at the documentation in your browser (
build/doc/index.html)
- inside your sasmodels directory:
-
if you want to see what that looks like inside SasView,
- inside your sasmodels directory:
python -m pip install --no-build-isolation -e .(⚠️ this is a new(ish) step and will generated puzzling results if forgotten) - inside your sasview directory:
python -m pip install --no-build-isolation -e . - start SasView and look at the help
- inside your sasmodels directory:
-
-
sasdata: you change documentation in
sasdata- same as for sasmodels, above
-
sasview: you change documentation in
sasview- inside your sasview directory:
python -m pip install --no-build-isolation -e . - look at the documentation in your browser (
build/doc/index.html) - start SasView and look at the help
- inside your sasview directory:
If you intend to repeat this many many times, you can speed it up:
--no-build-isolationas shown above builds without creating a new temporary venv- set
SASMODELS_BUILD_CACHEin your environment so sasmodels will cache the figures from sasmodels, e.g.export SASMODELS_BUILD_CACHE=~/.cache/sasmodels-figures. (You need to empty the cache yourself from time to time; see the documentation inside sasmodels for details, suggestions and other caveats.) - fundamentally, the slow part is always (and always was) running sphinx to render the documentation
When pip does an editable install, it does 3 things
that you will be able to see in your venv's site-packages (e.g. .venv/lib/python3.X/site-packages/):
- adds the
sasview-X.Y.Z.dist-infometadata directory that tells Python that the module is installed, along with details like its version, dependencies, file manifest - places a
_sasview.pthfile that tells the import machinery where to find the module code and embedded resources; this will point to thesrcdirectory inside your sasview git clone. - creates a
sasdirectory that contains only the files that don't live in the "right" place in git and therefore do not sit in the filesystem in the correct location for the editable install.
(For a regular installation rather than an editable installation, the .pth file would not exist and all the module files would be in that sas directory.)
More information can be found at: