1. Database stores a file version, so we can add to it in the future.
2. Database indexed by hashes and not numerical indexes.
3. Specs built by database have consistent hashes and it's checked.
4. minor naming and whitespace changes.
Most importantly wrote the Lock, Read_Lock_Instance, and Write_Lock_Instance classes in lock.py
Updated the locking in database.py
TODO: Lock on larger areas
Replaced them all with references to the database
Implemented caching in the database. The database now only re-reads data
if the database file exists and was changed since this file last wrote to it.
Added the installed_db field to the spack instance
Left the call to all_specs from testdirectory_layout.py for now.
No methods use the database so far.
Also, a bug fix:
Previous version did not remove the staging directory on a failed install
This led to spack refusing to uninstall dependencies of the failed install
Added to cleanup() to blow away the staging directory on failed install.
Certain remote protocols don't support the `--depth` option. Since this can't
be checked by URL type or in any sane way locally, this version attempts to
clone git repositories with the --depth option, and if that fails attempts the
clone again without it.
Ensures all tags are ready before checkout, using `--branch` if possible and
an extra pull if that is not available. Also adds `--depth 1` to create
shallow clones if the git version is sufficient.
Fixes#64.
It is currently less painful to pull the source from github, compile it into a
gem, then install the gem, than it is to download a gem and install it. This
still lacks an activation mechanism, but `spack use tmuxinator` is functional.
- This can result in the user being prompted to download an unsafe
version.
- Avoids overly strict errors when something *could* be satisfiable
but we don't know about hte version.
- The following now work differently:
spec['mpi']
spec['blas']
This can return a spec for openmpi, mpich, mvapich, etc., EVEN if
the spec is already concretized. This means that in a package that
`depends_on('mpi')`, you can do `spec['mpi']` to see what it was
concretized to. This should simplify MPI and BLAS packages.
'mpi' in spec
'blas' in spec
Previously, if the spec had been concretized, these would be `False`
because there was not a dependency in the DAG with either of these
names. These will now be `True` even if the spec has been
concretized. So, e.g., this will print "YES"
s = Spec('callpath ^mpich')
if 'mpi' in spec:
print "YES"
- Similarly, this will be True:
Spec('mpich').satisfies('mpi')
- Because of the way virtual dependencies are currently implemented,
the above required some fiddling around with `package.py` so that it
would never call `Spec.__contains__` (and result in endless
recursion).
- This should be fixed by allowing virutal dependnecies to have their
own package class.
- This would allow a quicker check for vdeps, without a call to
`all_packages`.
- For the time being, `package.py` shouldn't call `__contains__`
- Expanding archvies like MAGMA 1.6.2 creates extra hidden files that
confuse Spack's staging mechanism.
- Added a special case to ignore hidden files when checking whether
the tarball exploded.
- spack install suppresses build output by default.
- use install -v to show build output on the console too
- package.py uses log_output context to redirect output and log it to a file
- filters color codes out of output written to file
- optionally echos to the terminal
- YAML directory layout knows about its build log.
- can get path to install build log to from directory layout
- Package.install now copies the build log to $prefix/.spack/build.out
- Error message from failed install execution now includes build log location
