* add first version of py-pyrr package
* added license
* update license HEADER
* Remove preferred as there is only one version available
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Better specify dependency type
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* remove useless variable license
Co-authored-by: Jérôme Dubois <jerome.dubois@cea.fr>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Add missing '?full_index=1' to meson 9850.patch URL
* Correct checksum
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
Co-authored-by: Massimiliano Culpo <massimiliano.culpo@gmail.com>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Fixed a bug in the 'external find --all' command where the call failed
to find packages by both executable and library. The bug was that the
call `path.all_packages()` incorrectly turned the variable
`packages_to_check` into a generator rather than keeping it a list.
Thus the second call to `detection.by_library` had no work to do.
* Fixed the help message for the find external and compiler commands as
well as others that used the `scopes_metavar` field to define where
the results should be stored in configuration space. Specifically,
the fact that configuration could be added to the environment was not
mentioned in the help message.
os.path.dirname was being used to compare compilers. If two compilers
are in the same directory then it will pick up the first one it encounters.
Compare the full compiler path instead.
When installing setuptools from sources in Spack, we might
get into weird failures due to the way we use pip.
In particular, for Spack it's necessary to install in a
non-isolated pip environment to allow using PYTHONPATH as a
selection method for all the build requirements of a
Python package.
This can fail when installing setuptools since there might
be a setuptools version already installed for the Python
interpreter being used, with different entry points than
the one we want to install.
Installing from wheels both pip and setuptools should
harden our installation procedure in the context of:
- Bootstrapping Python dependencies of Spack
- Using external Python packages
On Cray systems that use Cray Data Virtualization Service (DVS),
symlinks across filesystems are not allowed, either due to a bug, or
because they're simply not POSIX compliant [1].
Spack's OpenSSL package defaults to `certs=system` which comes down to
symlinking `/etc/ssl` in the Spack install prefix, triggering this
problem, resulting in mysterious installation failures.
Instead of relying on system certs, we can just use
`ca-certificates-mozilla`, and if users really need system certs, then
they're probably better off marking OpenSSL entirely as external.
[1] https://github.com/glennklockwood/cray-dvs
* Created package and added description
* Add py-markdown-include
* Created package
* Finished creating package
* Added py-md-environ
* Added build dependencies
* Added other deps
* Add python-markdown-math (#4)
* Created package and started to add info
* Removed unneeded global/install options
* Figured out version spec for markdown-math
* Removed type=build from unnecessary dependencies
* Removed unneeded install/global options, added version spec to dependency
* Added wscullin as interim maintainer for packages
* Fixed style issues
* Took care of trailing whitespace
* Removed comment line before imports
* Changed file charset to match other packages
* Update var/spack/repos/builtin/packages/py-ford/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Update var/spack/repos/builtin/packages/py-ford/package.py
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Removed test dependency after review feedback
* Added new 6.1.12 version to py-ford
Co-authored-by: Seth R. Johnson <johnsonsr@ornl.gov>
Co-authored-by: Adam J. Stewart <ajstewart426@gmail.com>
* Add LevelZero variant to hwloc package
This permits the hwloc package to build with with support for the
Intel Level Zero low-level layer, analogous to CUDA, ROCm, and OpenCL.
* Fix typo
