Commit Graph

27 Commits

Author SHA1 Message Date
Adam J. Stewart
603569e321
Style: black 23, skip magic trailing comma (#35351)
* 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-02-16 23:06:12 -06:00
Massimiliano Culpo
ddecf07045
Use the maintainers directive in all packages (#35201) 2023-02-01 21:07:25 -08:00
Harmen Stoppels
fce95e2efb
license year bump (#34921)
* license bump year
* fix black issues of modified files
* mypy
* fix 2021 -> 2023
2023-01-18 14:30:17 -08:00
Christian Kniep
7637efb363
blast-plus: update to 2.13.0 and add cpio as build dependency (#33187) 2022-11-17 03:42:25 +01:00
Todd Gamblin
f52f6e99db black: reformat entire repository with black 2022-07-31 13:29:20 -07:00
Tom Scogland
18c2f1a57a
refactor: packages import spack.package explicitly (#30404)
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-05-28 12:55:44 -04:00
Todd Gamblin
93377942d1 Update copyright year to 2022 2022-01-14 22:50:21 -08:00
Vanessasaurus
6a26322eb3
fixing "problems in speck" as identified by repology (#25491)
Most of these are perl packages that need to point to the meta docs site,
and then a fair amount of http addresses that need to be https, and then
the rest are usually documentation sites that no longer exist or were
otherwise changes

Signed-off-by: vsoch <vsoch@users.noreply.github.com>

Co-authored-by: vsoch <vsoch@users.noreply.github.com>
2021-08-26 15:05:24 -05:00
Jianwen
657b3ec052
blast-plus: add version 2.12.0 (#24828) 2021-07-13 10:44:07 -07:00
Todd Gamblin
a8ccb8e116 copyrights: update all files with license headers for 2021
- [x] add `concretize.lp`, `spack.yaml`, etc. to licensed files
- [x] update all licensed files to say 2013-2021 using
      `spack license update-copyright-year`
- [x] appease mypy with some additions to package.py that needed
      for oneapi.py
2021-01-02 12:12:00 -08:00
Desmond Orton
c65090bac1
blast-plus: added v2.11.0 (#20024)
Co-authored-by: Dan Han <las_danhan@iastate.edu>
2020-12-02 20:02:14 +01:00
Todd Gamblin
4af6303086
copyright: update copyright dates for 2020 (#14328) 2019-12-30 22:36:56 -08:00
Todd Gamblin
62927654dd checksums: use sha256 checksums everywhere
We'd like to use a consistent checksum scheme everywhere so that we can:

    a) incorporate archive checksums into our specs and have a
       consistent hashing algorithm across all specs.

    b) index mirrors with a consistent type of checksum, and not one that
       is dependent on how spack packages are written.

- [x] convert existing md5, sha224, sha512, sha1 checksums to sha256
2019-10-12 07:19:43 -07:00
Massimiliano Culpo
90236bc9f5
Update target comparison semantic for a few packages (#12947)
Use spec.target.family instead of spec.architecture.target
2019-09-26 10:25:12 +02:00
Toyohisa Kameyama
ae8710fa36 blast-plus package: remove --with-64 on ARM. (#11877)
This configure option is not supported on ARM
2019-06-28 10:11:04 -07:00
Owen Solberg
c031cff2bc BLAST-Plus package: add versions 2.9.0 and 2.8.1 (#11333) 2019-05-04 03:33:35 +09:00
Todd Gamblin
6f50cd52ed copyright: update license headers for 2013-2019 copyright. 2019-01-01 00:44:28 -08:00
Todd Gamblin
eea786f4e8 relicense: replace LGPL headers with Apache-2.0/MIT SPDX headers
- remove the old LGPL license headers from all files in Spack
- add SPDX headers to all files
  - core and most packages are (Apache-2.0 OR MIT)
  - a very small number of remaining packages are LGPL-2.1-only
2018-10-17 14:42:06 -07:00
Dan Han
5cafe1b4e8 blastplus: newest version 2.7.1 (#9472) 2018-10-09 13:22:34 -07:00
Todd Gamblin
54f97d1dec
Update copyright on LLNL files for 2018. (#7592) 2018-03-24 12:13:52 -07:00
Todd Gamblin
05fa302655
Replace github.com/llnl/spack with github.com/spack/spack (#6142)
We moved to a new GitHub org! Now make the code and docs reflect that.
2017-11-04 17:08:04 -07:00
Michael Kuhn
84ae7872d3 Update copyright notices for 2017 (#5295) 2017-09-06 17:44:16 -10:00
Todd Gamblin
cac4362f64 Make LICENSE recognizable by GitHub. (#4598) 2017-06-24 22:22:55 -07:00
Adam J. Stewart
ce3ab503de Python command, libraries, and headers (#3367)
## Motivation

Python installations are both important and unfortunately inconsistent. Depending on the Python version, OS, and the strength of the Earth's magnetic field when it was installed, the name of the Python executable, directory containing its libraries, library names, and the directory containing its headers can vary drastically. 

I originally got into this mess with #3274, where I discovered that Boost could not be built with Python 3 because the executable is called `python3` and we were telling it to use `python`. I got deeper into this mess when I started hacking on #3140, where I discovered just how difficult it is to find the location and name of the Python libraries and headers.

Currently, half of the packages that depend on Python and need to know this information jump through hoops to determine the correct information. The other half are hard-coded to use `python`, `spec['python'].prefix.lib`, and `spec['python'].prefix.include`. Obviously, none of these packages would work for Python 3, and there's no reason to duplicate the effort. The Python package itself should contain all of the information necessary to use it properly. This is in line with the recent work by @alalazo and @davydden with respect to `spec['blas'].libs` and friends.

## Prefix

For most packages in Spack, we assume that the installation directory is `spec['python'].prefix`. This generally works for anything installed with Spack, but gets complicated when we include external packages. Python is a commonly used external package (it needs to be installed just to run Spack). If it was installed with Homebrew, `which python` would return `/usr/local/bin/python`, and most users would erroneously assume that `/usr/local` is the installation directory. If you peruse through #2173, you'll immediately see why this is not the case. Homebrew actually installs Python in `/usr/local/Cellar/python/2.7.12_2` and symlinks the executable to `/usr/local/bin/python`. `PYTHONHOME` (and presumably most things that need to know where Python is installed) needs to be set to the actual installation directory, not `/usr/local`.

Normally I would say, "sounds like user error, make sure to use the real installation directory in your `packages.yaml`". But I think we can make a special case for Python. That's what we decided in #2173 anyway. If we change our minds, I would be more than happy to simplify things.

To solve this problem, I created a `spec['python'].home` attribute that works the same way as `spec['python'].prefix` but queries Python to figure out where it was actually installed. @tgamblin Is there any way to overwrite `spec['python'].prefix`? I think it's currently immutable.

## Command

In general, Python 2 comes with both `python` and `python2` commands, while Python 3 only comes with a `python3` command. But this is up to the OS developers. For example, `/usr/bin/python` on Gentoo is actually Python 3. Worse yet, if someone is using an externally installed Python, all 3 commands may exist in the same directory! Here's what I'm thinking:

If the spec is for Python 3, try searching for the `python3` command.
If the spec is for Python 2, try searching for the `python2` command.
If neither are found, try searching for the `python` command.

## Libraries

Spack installs Python libraries in `spec['python'].prefix.lib`. Except on openSUSE 13, where it installs to `spec['python'].prefix.lib64` (see #2295 and #2253). On my CentOS 6 machine, the Python libraries are installed in `/usr/lib64`. Both need to work.

The libraries themselves change name depending on OS and Python version. For Python 2.7 on macOS, I'm seeing:
```
lib/libpython2.7.dylib
```
For Python 3.6 on CentOS 6, I'm seeing:
```
lib/libpython3.so
lib/libpython3.6m.so.1.0
lib/libpython3.6m.so -> lib/libpython3.6m.so.1.0
```
Notice the `m` after the version number. Yeah, that's a thing.

## Headers

In Python 2.7, I'm seeing:
```
include/python2.7/pyconfig.h
```
In Python 3.6, I'm seeing:
```
include/python3.6m/pyconfig.h
```
It looks like all Python 3 installations have this `m`. Tested with Python 3.2 and 3.6 on macOS and CentOS 6

Spack has really nice support for libraries (`find_libraries` and `LibraryList`), but nothing for headers. Fixed.
2017-04-29 17:24:13 -07:00
George Hartzell
33c9a91d85 Make perl and python variants (#3992)
The blast+ configure script supports building
--with-{python,perl}=path and --without-{python,perl}.

This commit makes the use of those two languages configurable via
variants and adds dependencies and explicit --with-... or
--without-... flags to configure.

Python was a non-optional dependency, now it is a variant that
defaults to `True`.

Perl was not previously an explicit dependency but the configure
script was likely to discover one on your system (`/usr/bin/perl`).
It is now a variant that defaults to `True`.

I am unable to accurately determine what these flags to the configure
script enable.  My users are frustrated by the dependency on Python in
particular because it constrains the other modules that they can have
loaded for new discernible benefit.
2017-04-26 06:04:20 +02:00
Adam J. Stewart
50df071ad9 Overhaul Spack's URL parsing (#2972)
* Remove fake URLs from Spack

* Ignore long lines for URLs that start with ftp:

* Preliminary changes to version regexes

* New redesign of version regexes

* Allow letters in version-only

* Fix detection of versions that end in Final

* Rearrange a few regexes and add examples

* Add tests for common download repositories

* Add test cases for common tarball naming schemes

* Finalize version regexes

* spack url test -> spack url summary

* Clean up comments

* Rearrange suffix checks

* Use query strings for name detection

* Remove no longer necessary url_for_version functions

* Strip off extraneous information after package name

* Add one more test

* Dot in square brackets does not need to be escaped

* Move renaming outside of parse_name_offset

* Fix versions for a couple more packages

* Fix flake8 and doc tests

* Correctly parse Python, Lua, and Bio++ package names

* Use effective URLs for mfem

* Add checksummed version to mitos

* Remove url_for_version from STAR-CCM+ package

* Revert changes to version numbers with underscores and dashes

* Fix name detection for tbb

* Correctly parse Ruby gems

* Reverted mfem back to shortened URLs.

* Updated instructions for better security

* Remove preferred=True from newest version

* Add tests for new `spack url list` flags

* Add tests for strip_name_suffixes

* Add unit tests for version separators

* Fix bugs related to parseable name but in parseable version

* Remove dead code, update docstring

* Ignore 'binary' at end of version string

* Remove platform from version

* Flip libedit version numbers

* Re-support weird NCO alpha/beta versions

* Rebase and remove one new fake URL

* Add / to beginning of regex to avoid picking up similarly named packages

* Ignore weird tar versions

* Fix bug in url parse --spider when no versions found

* Less strict version matching for spack versions

* Don't rename Python packages

* Be a little more selective, version must begin with a digit

* Re-add fake URLs

* Fix up several other packages

* Ignore more file endings

* Add parsing support for Miniconda

* Update tab completion

* XFAILS are now PASSES for 2 web tests
2017-04-03 15:34:16 -07:00
George Hartzell
f5bc42f229 Add Blast+ package. (#3562)
* Add Blast+ package.

Adds support for NCBI's blast+@2.6.0.  I'll be adding a few historical versions in the near future.

It's a fairly direct transliteration of the [Homebrew Science recipe][hbs].

I skipped the mysql support.

There is a problem with HDF5 support.  Blast's configure script test program defines a macro 'HOST' to a string value and one of the HDF5 bits has an variable named 'HOST'.  Fun things happen.   I've disabled support for now.

I've run very very basic tests.  I'll get this out to my users and ensure that it works and fine tune the options and etc....

[hbs]: https://github.com/Homebrew/homebrew-science/blob/master/blast.rb

* Flake8 fixes

* Update w.t.r. mamelara's PR and cleanup

Add paths to things in the --with-* config args

Add add'l config flags from #3394.

Update patch to no-op and add comment.

Add add'l dependencies after studying `configure --help`.

* Flake8 cleanup

* Add support for blast+@2.2.30

Need to work around a configure bug.  See https://github.com/Homebrew/homebrew-science/issues/2337#issuecomment-170011511.

* Re-wrap comment, line length not a problem.

I'd broken a comment across to line in a fit of flake8
induced fear.  Adam pointed out that it's ok.

* Remove explicit prefix config

Remove explicit prefix config, the autotools package does it for us.
2017-03-28 21:38:51 -05:00