summaryrefslogtreecommitdiff
path: root/pyproject.toml
AgeCommit message (Collapse)AuthorFilesLines
2023-02-16Style: black 23, skip magic trailing comma (#35351)Adam J. Stewart1-1/+3
* Style: black 23, skip magic trailing commas * isort should use same line length as black * Fix unused import * Update version of black used in CI * Update new packages * Update new packages
2023-01-04Use "vendoring" to manage 3rd party dependenciesMassimiliano Culpo1-4/+42
2023-01-01style: fix spurious `mypy` errors from `numpy` (#34732)Todd Gamblin1-3/+6
Spack imports `pytest`, which *can* import `numpy`. Recent versions of `numpy` require Python 3.8 or higher, and they use 3.8 type annotations in their type stubs (`.pyi` files). At the same time, we tell `mypy` to target Python 3.7, as we still support older versions of Python. What all this means is that if you run `mypy` on `spack`, `mypy` will follow all the static import statements, and it ends up giving you this error when it finds numpy stuff that is newer than the target Python version: ``` ==> Running mypy checks src/spack/var/spack/environments/default/.spack-env/._view/4g7jd4ibkg4gopv4rosq3kn2vsxrxm2f/lib/python3.11/site-packages/numpy/__init__.pyi:638: error: Positional-only parameters are only supported in Python 3.8 and greater [syntax] Found 1 error in 1 file (errors prevented further checking) mypy found errors ``` We can fix this by telling `mypy` to skip all imports of `numpy` in `pyproject.toml`: ```toml [[tool.mypy.overrides]] module = 'numpy' follow_imports = 'skip' follow_imports_for_stubs = true ``` - [x] don't follow imports from `numpy` in `mypy` - [x] get rid of old rule not to follow `jinja2` imports, as we now require Python 3
2022-11-14Remove support for running with Python 2.7 (#33063)Massimiliano Culpo1-1/+1
* Remove CI jobs related to Python 2.7 * Remove Python 2.7 specific code from Spack core * Remove externals for Python 2 only * Remove llnl.util.compat
2022-11-07encode development requirements in pyproject.toml (#32616)Tom Scogland1-0/+71
Add a `project` block to the toml config along with development and CI dependencies and a minimal `build-system` block, doing basically nothing, so that spack can be bootstrapped to a full development environment with: ```shell $ hatch -e dev shell ``` or for a minimal environment without hatch: ```shell $ python3 -m venv venv $ source venv/bin/activate $ python3 -m pip install --upgrade pip $ python3 -m pip install -e '.[dev]' ``` This means we can re-use the requirements list throughout the workflow yaml files and otherwise maintain this list in *one place* rather than several disparate ones. We may be stuck with a couple more temporarily to continue supporting python2.7, but aside from that it's less places to get out of sync and a couple new bootstrap options. Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
2022-09-10ci: restore coverage computation (#32585)Massimiliano Culpo1-0/+1
* ci: restore coverage computation * Mark "test_foreground_background" as xfail * Mark "test_foreground_background_output" as xfail * Make number of processes explicit, remove verbosity on linux * Run coverage on just 3 Python jobs for linux * Run coverage on just 3 Python jobs for linux * Run coverage on just 2 Python jobs for linux * Add back verbose, since before we didn't encounter the xdist internal error * Reduce the workers to 2 * Try to use command line
2022-07-31black: configurationTodd Gamblin1-0/+15
This adds necessary configuration for flake8 and black to work together. This also sets the line length to 99, per the data here: * https://github.com/spack/spack/pull/24718#issuecomment-876933636 Given the data and the spirit of black's 88-character limit, we set the limit to 99 characters for all of Spack, because: * 99 is one less than 100, a nice round number, and all lines will fit in a 100-character wide terminal (even when the text editor puts a \ at EOL). * 99 is just past the knee the file size curve for packages, and it means that packages remain readable and not significantly longer than they are now. * It doesn't seem to hurt core -- files in core might change length by a few percent but seem like they'll be mostly the same as before -- just a bit more roomy. - [x] set line length to 99 - [x] remove most exceptions from `.flake8` and add the ones black cares about - [x] add `[tool.black]` to `pyproject.toml` - [x] make `black` run if available in `spack style --fix` Co-Authored-By: Tom Scogland <tscogland@llnl.gov>
2022-05-28refactor: packages import `spack.package` explicitly (#30404)Tom Scogland1-1/+13
Explicitly import package utilities in all packages, and corresponding fallout. This includes: * rename `spack.package` to `spack.package_base` * rename `spack.pkgkit` to `spack.package` * update all packages in builtin, builtin_mock and tutorials to include `from spack.package import *` * update spack style * ensure packages include the import * automatically add the new import and remove any/all imports of `spack` and `spack.pkgkit` from packages when using `--fix` * add support for type-checking packages with mypy when SPACK_MYPY_CHECK_PACKAGES is set in the environment * fix all type checking errors in packages in spack upstream * update spack create to include the new imports * update spack repo to inject the new import, injection persists to allow for a deprecation period Original message below: As requested @adamjstewart, update all packages to use pkgkit. I ended up using isort to do this, so repro is easy: ```console $ isort -a 'from spack.pkgkit import *' --rm 'spack' ./var/spack/repos/builtin/packages/*/package.py $ spack style --fix ``` There were several line spacing fixups caused either by space manipulation in isort or by packages that haven't been touched since we added requirements, but there are no functional changes in here. * [x] add config to isort to make sure this is maintained going forward
2022-01-21introduce `llnl.util.compat` to remove sys.version_info checks (#21720)Danny McClanahan1-0/+1
- also split typing.py into typing_extensions and add py2 shims
2021-07-09coverage: move config from `.coveragerc` to `pyproject.toml`Todd Gamblin1-27/+63
Getting rid of another top-level file. `coverage.py` has supported `pyproject.toml` since version 5.0, and all versions of coverage so far work with python 2.7. We just need to ensure that a version of coverage with the `toml` extra is installed in the test environment. I tested this with `coverage run`, `coverage report`, and `coverage html`.
2021-07-09mypy: move configuration to pyproject.toml (#24802)Todd Gamblin1-0/+44
This moves our `mypy` configuration from `.mypy.ini` to `.pyproject.toml` and increases the minimum `mypy` version in the tests. - [x] move `mypy` configuration to `pyproject.toml` - [x] remove `.mypy.ini` - [x] ensure that `mypy` version .900 or higher is used in tests
2021-07-07style: Move isort configuration to pyproject.tomlTodd Gamblin1-0/+14
- [x] Remove flake8-import-order checks, as we only need isort for this - [x] Clean up configuration and requirements