Skip to content

Commit 0f54a63

Browse files
haampiehaampie
authored
remove activate/deactivate support in favor of environments (#29317)
Environments and environment views have taken over the role of `spack activate/deactivate`, and we should deprecate these commands for several reasons: - Global activation is a really poor idea: - Install prefixes should be immutable; since they can have multiple, unrelated dependents; see below - Added complexity elsewhere: verification of installations, tarballs for build caches, creation of environment views of packages with unrelated extensions "globally activated"... by removing the feature, it gets easier for people to contribute, and we'd end up with fewer bugs due to edge cases. - Environment accomplish the same thing for non-global "activation" i.e. `spack view`, but better. Also we write in the docs: ``` However, Spack global activations have two potential drawbacks: #. Activated packages that involve compiled C extensions may still need their dependencies to be loaded manually. For example, ``spack load openblas`` might be required to make ``py-numpy`` work. #. Global activations "break" a core feature of Spack, which is that multiple versions of a package can co-exist side-by-side. For example, suppose you wish to run a Python package in two different environments but the same basic Python --- one with ``[email protected]`` and one with ``[email protected]``. Spack extensions will not support this potential debugging use case. ``` Now that environments are established and views can take over the role of activation non-destructively, we can remove global activation/deactivation.
1 parent f11778b commit 0f54a63

24 files changed

+34
-1708
lines changed

‎lib/spack/docs/basic_usage.rst‎

Lines changed: 12 additions & 127 deletions
Original file line numberDiff line numberDiff line change
@@ -1114,21 +1114,21 @@ set of arbitrary versions, such as ``@1.0,1.5,1.7`` (``1.0``, ``1.5``,
11141114
or ``1.7``). When you supply such a specifier to ``spack install``,
11151115
it constrains the set of versions that Spack will install.
11161116

1117-
For packages with a ``git`` attribute, ``git`` references
1118-
may be specified instead of a numerical version i.e. branches, tags
1119-
and commits. Spack will stage and build based off the ``git``
1117+
For packages with a ``git`` attribute, ``git`` references
1118+
may be specified instead of a numerical version i.e. branches, tags
1119+
and commits. Spack will stage and build based off the ``git``
11201120
reference provided. Acceptable syntaxes for this are:
11211121

11221122
.. code-block:: sh
1123-
1123+
11241124
# branches and tags
11251125
[email protected] # use the develop branch
11261126
[email protected] # use the 0.19 tag
1127-
1127+
11281128
# commit hashes
11291129
foo@abcdef1234abcdef1234abcdef1234abcdef1234 # 40 character hashes are automatically treated as git commits
11301130
[email protected]
1131-
1131+
11321132
Spack versions from git reference either have an associated version supplied by the user,
11331133
or infer a relationship to known versions from the structure of the git repository. If an
11341134
associated version is supplied by the user, Spack treats the git version as equivalent to that
@@ -1745,13 +1745,13 @@ directly when you run ``python``:
17451745
Using Extensions
17461746
^^^^^^^^^^^^^^^^
17471747

1748-
There are four ways to get ``numpy`` working in Python. The first is
1748+
There are multiple ways to get ``numpy`` working in Python. The first is
17491749
to use :ref:`shell-support`. You can simply ``load`` the extension,
1750-
and it will be added to the ``PYTHONPATH`` in your current shell:
1750+
and it will be added to the ``PYTHONPATH`` in your current shell, and
1751+
Python itself will be available in the ``PATH``:
17511752

17521753
.. code-block:: console
17531754
1754-
$ spack load python
17551755
$ spack load py-numpy
17561756
17571757
Now ``import numpy`` will succeed for as long as you keep your current
@@ -1777,128 +1777,13 @@ load, you can use the ``spack module tcl|lmod loads`` command to get
17771777
the name of the module from the Spack spec.
17781778

17791779
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1780-
Activating Extensions in a View
1780+
Extensions in an Environment
17811781
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
17821782

17831783
Another way to use extensions is to create a view, which merges the
17841784
python installation along with the extensions into a single prefix.
1785-
See :ref:`configuring_environment_views` for a more in-depth description
1786-
of views.
1787-
1788-
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1789-
Activating Extensions Globally
1790-
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
1791-
1792-
As an alternative to creating a merged prefix with Python and its extensions,
1793-
and prior to support for views, Spack has provided a means to install the
1794-
extension into the Spack installation prefix for the extendee. This has
1795-
typically been useful since extendable packages typically search their own
1796-
installation path for addons by default.
1797-
1798-
Global activations are performed with the ``spack activate`` command:
1799-
1800-
.. _cmd-spack-activate:
1801-
1802-
^^^^^^^^^^^^^^^^^^
1803-
``spack activate``
1804-
^^^^^^^^^^^^^^^^^^
1805-
1806-
.. code-block:: console
1807-
1808-
$ spack activate py-numpy
1809-
==> Activated extension [email protected]%[email protected] arch=linux-debian7-x86_64-3c74eb69 for [email protected]%[email protected].
1810-
==> Activated extension [email protected]%[email protected] arch=linux-debian7-x86_64-5f70f816 for [email protected]%[email protected].
1811-
==> Activated extension [email protected]%[email protected] arch=linux-debian7-x86_64-66733244 for [email protected]%[email protected].
1812-
1813-
Several things have happened here. The user requested that
1814-
``py-numpy`` be activated in the ``python`` installation it was built
1815-
with. Spack knows that ``py-numpy`` depends on ``py-nose`` and
1816-
``py-setuptools``, so it activated those packages first. Finally,
1817-
once all dependencies were activated in the ``python`` installation,
1818-
``py-numpy`` was activated as well.
1819-
1820-
If we run ``spack extensions`` again, we now see the three new
1821-
packages listed as activated:
1822-
1823-
.. code-block:: console
1824-
1825-
$ spack extensions python
1826-
==> [email protected]%[email protected] arch=linux-debian7-x86_64-703c7a96
1827-
==> 36 extensions:
1828-
geos py-ipython py-pexpect py-pyside py-sip
1829-
py-basemap py-libxml2 py-pil py-pytz py-six
1830-
py-biopython py-mako py-pmw py-rpy2 py-sympy
1831-
py-cython py-matplotlib py-pychecker py-scientificpython py-virtualenv
1832-
py-dateutil py-mpi4py py-pygments py-scikit-learn
1833-
py-epydoc py-mx py-pylint py-scipy
1834-
py-gnuplot py-nose py-pyparsing py-setuptools
1835-
py-h5py py-numpy py-pyqt py-shiboken
1836-
1837-
==> 12 installed:
1838-
-- linux-debian7-x86_64 / [email protected] --------------------------------
1839-
[email protected] [email protected] [email protected]
1840-
[email protected] [email protected] [email protected]
1841-
[email protected] [email protected] [email protected]
1842-
[email protected] [email protected] [email protected]
1843-
1844-
==> 3 currently activated:
1845-
-- linux-debian7-x86_64 / [email protected] --------------------------------
1846-
[email protected] [email protected] [email protected]
1847-
1848-
Now, when a user runs python, ``numpy`` will be available for import
1849-
*without* the user having to explicitly load it. ``[email protected]`` now
1850-
acts like a system Python installation with ``numpy`` installed inside
1851-
of it.
1852-
1853-
Spack accomplishes this by symbolically linking the *entire* prefix of
1854-
the ``py-numpy`` package into the prefix of the ``python`` package. To the
1855-
python interpreter, it looks like ``numpy`` is installed in the
1856-
``site-packages`` directory.
1857-
1858-
The only limitation of global activation is that you can only have a *single*
1859-
version of an extension activated at a time. This is because multiple
1860-
versions of the same extension would conflict if symbolically linked
1861-
into the same prefix. Users who want a different version of a package
1862-
can still get it by using environment modules or views, but they will have to
1863-
explicitly load their preferred version.
1864-
1865-
^^^^^^^^^^^^^^^^^^^^^^^^^^
1866-
``spack activate --force``
1867-
^^^^^^^^^^^^^^^^^^^^^^^^^^
1868-
1869-
If, for some reason, you want to activate a package *without* its
1870-
dependencies, you can use ``spack activate --force``:
1871-
1872-
.. code-block:: console
1873-
1874-
$ spack activate --force py-numpy
1875-
==> Activated extension [email protected]%[email protected] arch=linux-debian7-x86_64-66733244 for [email protected]%[email protected].
1876-
1877-
.. _cmd-spack-deactivate:
1878-
1879-
^^^^^^^^^^^^^^^^^^^^
1880-
``spack deactivate``
1881-
^^^^^^^^^^^^^^^^^^^^
1882-
1883-
We've seen how activating an extension can be used to set up a default
1884-
version of a Python module. Obviously, you may want to change that at
1885-
some point. ``spack deactivate`` is the command for this. There are
1886-
several variants:
1887-
1888-
* ``spack deactivate <extension>`` will deactivate a single
1889-
extension. If another activated extension depends on this one,
1890-
Spack will warn you and exit with an error.
1891-
* ``spack deactivate --force <extension>`` deactivates an extension
1892-
regardless of packages that depend on it.
1893-
* ``spack deactivate --all <extension>`` deactivates an extension and
1894-
all of its dependencies. Use ``--force`` to disregard dependents.
1895-
* ``spack deactivate --all <extendee>`` deactivates *all* activated
1896-
extensions of a package. For example, to deactivate *all* python
1897-
extensions, use:
1898-
1899-
.. code-block:: console
1900-
1901-
$ spack deactivate --all python
1785+
See :ref:`environments` for a more in-depth description
1786+
of environment views.
19021787

19031788
-----------------------
19041789
Filesystem requirements

‎lib/spack/docs/contribution_guide.rst‎

Lines changed: 2 additions & 27 deletions
Original file line numberDiff line numberDiff line change
@@ -253,27 +253,6 @@ to update them.
253253
multiple runs of ``spack style`` just to re-compute line numbers and
254254
makes it much easier to fix errors directly off of the CI output.
255255

256-
.. warning::
257-
258-
Flake8 and ``pep8-naming`` require a number of dependencies in order
259-
to run. If you installed ``py-flake8`` and ``py-pep8-naming``, the
260-
easiest way to ensure the right packages are on your ``PYTHONPATH`` is
261-
to run::
262-
263-
spack activate py-flake8
264-
spack activate pep8-naming
265-
266-
so that all of the dependencies are symlinked to a central
267-
location. If you see an error message like:
268-
269-
.. code-block:: console
270-
271-
Traceback (most recent call last):
272-
File: "/usr/bin/flake8", line 5, in <module>
273-
from pkg_resources import load_entry_point
274-
ImportError: No module named pkg_resources
275-
276-
that means Flake8 couldn't find setuptools in your ``PYTHONPATH``.
277256

278257
^^^^^^^^^^^^^^^^^^^
279258
Documentation Tests
@@ -309,13 +288,9 @@ All of these can be installed with Spack, e.g.
309288

310289
.. code-block:: console
311290
312-
$ spack activate py-sphinx
313-
$ spack activate py-sphinx-rtd-theme
314-
$ spack activate py-sphinxcontrib-programoutput
291+
$ spack load py-sphinx py-sphinx-rtd-theme py-sphinxcontrib-programoutput
315292
316-
so that all of the dependencies are symlinked into that Python's
317-
tree. Alternatively, you could arrange for their library
318-
directories to be added to PYTHONPATH. If you see an error message
293+
so that all of the dependencies are added to PYTHONPATH. If you see an error message
319294
like:
320295

321296
.. code-block:: console

‎lib/spack/docs/environments.rst‎

Lines changed: 2 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -233,8 +233,8 @@ packages will be listed as roots of the Environment.
233233

234234
All of the Spack commands that act on the list of installed specs are
235235
Environment-sensitive in this way, including ``install``,
236-
``uninstall``, ``activate``, ``deactivate``, ``find``, ``extensions``,
237-
and more. In the :ref:`environment-configuration` section we will discuss
236+
``uninstall``, ``find``, ``extensions``, and more. In the
237+
:ref:`environment-configuration` section we will discuss
238238
Environment-sensitive commands further.
239239

240240
^^^^^^^^^^^^^^^^^^^^^

‎lib/spack/docs/packaging_guide.rst‎

Lines changed: 0 additions & 61 deletions
Original file line numberDiff line numberDiff line change
@@ -2722,67 +2722,6 @@ extensions; as a consequence python extension packages (those inheriting from
27222722
``PythonPackage``) likewise override ``add_files_to_view`` in order to rewrite
27232723
shebang lines which point to the Python interpreter.
27242724

2725-
^^^^^^^^^^^^^^^^^^^^^^^^^
2726-
Activation & deactivation
2727-
^^^^^^^^^^^^^^^^^^^^^^^^^
2728-
2729-
Adding an extension to a view is referred to as an activation. If the view is
2730-
maintained in the Spack installation prefix of the extendee this is called a
2731-
global activation. Activations may involve updating some centralized state
2732-
that is maintained by the extendee package, so there can be additional work
2733-
for adding extensions compared with non-extension packages.
2734-
2735-
Spack's ``Package`` class has default ``activate`` and ``deactivate``
2736-
implementations that handle symbolically linking extensions' prefixes
2737-
into a specified view. Extendable packages can override these methods
2738-
to add custom activate/deactivate logic of their own. For example,
2739-
the ``activate`` and ``deactivate`` methods in the Python class handle
2740-
symbolic linking of extensions, but they also handle details surrounding
2741-
Python's ``.pth`` files, and other aspects of Python packaging.
2742-
2743-
Spack's extensions mechanism is designed to be extensible, so that
2744-
other packages (like Ruby, R, Perl, etc.) can provide their own
2745-
custom extension management logic, as they may not handle modules the
2746-
same way that Python does.
2747-
2748-
Let's look at Python's activate function:
2749-
2750-
.. literalinclude:: _spack_root/var/spack/repos/builtin/packages/python/package.py
2751-
:pyobject: Python.activate
2752-
:linenos:
2753-
2754-
This function is called on the *extendee* (Python). It first calls
2755-
``activate`` in the superclass, which handles symlinking the
2756-
extension package's prefix into the specified view. It then does
2757-
some special handling of the ``easy-install.pth`` file, part of
2758-
Python's setuptools.
2759-
2760-
Deactivate behaves similarly to activate, but it unlinks files:
2761-
2762-
.. literalinclude:: _spack_root/var/spack/repos/builtin/packages/python/package.py
2763-
:pyobject: Python.deactivate
2764-
:linenos:
2765-
2766-
Both of these methods call some custom functions in the Python
2767-
package. See the source for Spack's Python package for details.
2768-
2769-
^^^^^^^^^^^^^^^^^^^^
2770-
Activation arguments
2771-
^^^^^^^^^^^^^^^^^^^^
2772-
2773-
You may have noticed that the ``activate`` function defined above
2774-
takes keyword arguments. These are the keyword arguments from
2775-
``extends()``, and they are passed to both activate and deactivate.
2776-
2777-
This capability allows an extension to customize its own activation by
2778-
passing arguments to the extendee. Extendees can likewise implement
2779-
custom ``activate()`` and ``deactivate()`` functions to suit their
2780-
needs.
2781-
2782-
The only keyword argument supported by default is the ``ignore``
2783-
argument, which can take a regex, list of regexes, or a predicate to
2784-
determine which files *not* to symlink during activation.
2785-
27862725
.. _virtual-dependencies:
27872726

27882727
--------------------

‎lib/spack/spack/cmd/activate.py‎

Lines changed: 0 additions & 53 deletions
This file was deleted.

0 commit comments

Comments
 (0)