* Add py-wub, with supporting fixes
- add py-wub
- add py-pycmd because py-wub needs it
- update py-statsmodels, which needs at least v0.9.0 to work with
python3.7 because cython.
* Update based on Adam's comments
* Fix dependency types for py-six in py-wub
* statsmodels tests fail, update comment w/ Issue #
The statsmodels tests weren't run in the previous version of the
package. If I enable them, the fail.
Update the package comment with the statsmodels issue I opened to
track the problem:
https://github.com/statsmodels/statsmodels/issues/6263
* Update dependency types in py-wub/package.py
* flake8 cleanups
* Make statsmodels tests work
- need to use patsy@0.5.1:
- need to run the tests from within the build/lib* dir
* Add mg, a gnu-emacs like fork of microemacs
* Use Package, since not really an Autotools package
Switch from AutotoolsPackage to Package. Even though mg has a
configure script, it's not really an Autotools package.
* Need to also provide --prefix to configure
* Make relative binaries relocate text files properly
* rb strings aren't valid in python 2
* move perl to new interface for setup_environment family methods
* fix metis src dl url
* update ascent, vtk-h and vtk-m recipes
* update conduit package
* fix vtk-m shas
* mfem conduit fix
* use vtk-h develop
* fix issue with stripped include paths in mfem
* more metis fixes
* simpler fix for mfem conduit include issue
* finish mfem changes
* pin to cmake 3.14, since we hit cuda issues with 3.15
* add rtd theme as dep for ascent
* add vtk-h 0.5.0 release, update ascent to use it
* add ascent 0.5.0 release
* fix cmake pin to allow all vers of 3.14
* fix format string error in mfem pkg
* review fixes for mfem pkg
* review fixes for vtk-h and vtk-m packages
* address review comments for ascent pkg
* changing default off of develop broke downstream use
* revert prefed
* guile package: Handling the threads option.
Currently guile by default tries to compile its thread variant.
However, the threaded version can only be compiled if bdw-gc is
compiled with some threads support. Currently, the default
compilation of the bdw garbage collector is compiled without any
thread support resulting in a compilation error.
I have changed the the default guile compilation to the non-threaded
version. I have also added the appropiated options for the bdw-gc
compilation in case the user prefers the threaded variant.
* guile package(flake8): fixed identation issues
* z3:
* Fixed python dependency to always be required.
* bugfix about fallthrough annotation.
* z3: Add patch for before ver.4.4.1.
* Update var/spack/repos/builtin/packages/z3/package.py
Co-Authored-By: Adam J. Stewart <ajstewart426@gmail.com>
* Mark compiler/version conflict for CMake
Intel 14 lacks some C++11 features needed to compile new versions of
cmake.
```
/tmp/s3j/spack-stage/spack-stage-cmake-3.15.5-46lgp4ybhopy2p4rr66rxnew5iaddvmg/spack-src/Source/
cm_static_string_view.hxx(28): error: expected an operator
friend static_string_view operator"" _s(const char* data, size_t
^
```
* Mark compiler/version conflict for icu4c
With Intel 14.0.4 on Linux for icu4c 60.1 and higher:
```
locid.cpp(1156): error #1140: a using-declaration may not name a constructor or destructor
using KeywordEnumeration::KeywordEnumeration;
```
* Mark compiler/version conflict for nasm
Error installing `nasm@2.14.02%intel@14.0.4`:
```
In file included from nasmlib/crc64.c(35):
./include/nasmlib.h(116): error: expected a ";"
fatal_func nasm_assert_failed(const char *, int, const char *);
```
* Mark compiler/version conflict for bison
Installing `bison@3.4.2%intel@14.0.4`:
```
In file included from /tmp/s3j/spack-stage/spack-stage-bison-3.4.2-
uzjszv4owvqsymjpxtxvvegfavc6k5my/spack-src/lib/quotearg.c(33):
/tmp/s3j/spack-stage/spack-stage-bison-3.4.2-uzjszv4owvqsymjpxtxvvegfavc6k5my/spack-src/lib/
xalloc.h(51): warning #303: explicit type is missing ("int" assumed)
extern _Noreturn void xalloc_die (void);
```
* Mark compiler/version conflict for icu4c
With `icu4c@60.1%intel@16.0.4` and `icu4c@64.1%intel@16.0.4`:
```
In file included from ucurr.cpp(26):
static_unicode_sets.h(130): error #913: invalid multibyte character sequence
{POUND_SIGN, u'£'},
^
```
* Change conflict comments into messages
* py-matplotlib only needs backports when ^python@:2
This implements @scheibelp's suggestion in #13711.
py-matplotlib should only depends_on py-backports-functools-lru-cache
when it's using a python that actually *needs* it.
See #13711 for details.
* Don't depend_ons py-enum34 unless python@:3.3
* Tighten up enum34 dependency
@adamjstewart cracked open the setup.py files and suggested a tighter
dependency for py-enum34. 1.4 and 1.5 only require it for pythons
before 3.4, 1.3 requires it unconditionally. So...., we'll do the
same.
* Remove conflict on python 3.4 from enum34
at @adamjstewart's request see PR notes
