Skip to content

Commit cb56d86

Browse files
authored
Merge pull request #1241 from rosteen/fix-readthedocs-for-1.20
Ignore UnitBase and ConfigItem so 1.20.x docs will build
2 parents 73c3810 + 9b8726b commit cb56d86

File tree

3 files changed

+16
-54
lines changed

3 files changed

+16
-54
lines changed

CHANGES.rst

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -1,3 +1,11 @@
1+
1.20.3 (2025-06-13)
2+
-------------------
3+
4+
Bug Fixes
5+
^^^^^^^^^
6+
7+
- Ignore problematic astropy classes so docs will build. [#1241]
8+
19
1.20.2 (2025-05-27)
210
-------------------
311

docs/index.rst

Lines changed: 6 additions & 53 deletions
Original file line numberDiff line numberDiff line change
@@ -28,59 +28,12 @@ guiding document for spectroscopic development in the Astropy Project.
2828
development stage that some interfaces may change if user feedback and
2929
experience warrants it.
3030

31-
Changes coming in version 2.0
32-
=============================
33-
34-
Specutils 2.0 has been in development for some time and is nearly ready for release.
35-
The major changes that will affect users are detailed here in an attempt to prepare
36-
users for the transition.
37-
38-
The most visible change is that the `~specutils.Spectrum1D` class will be renamed
39-
to ``Spectrum`` to reduce confusion about multi-dimensional flux arrays being supported.
40-
The current class name will be deprecated in version 2.1; importing the old name will
41-
work but raise a deprecation warning until then. Version 1.20 implemented a ``Spectrum``
42-
class as a simple wrapper around `~specutils.Spectrum1D` so that you may update your
43-
code to the new class name now and avoid deprecation warnings when 2.0 releases. Note
44-
that the new keyword arguments ``move_spectral_axis`` and ``spectral_axis_index`` being
45-
introduced in 2.0 will be ignored in 1.x if used when initializing the ``Spectrum`` class.
46-
47-
Single-dimensional flux use cases should be mostly unchanged in 2.0, with the exception
48-
being that spectrum arithmetic will check that the spectral axis of both operands are
49-
equal, rather than simply checking that they are the same length. Thus, you will need
50-
to resample onto a common spectral axis if doing arithmetic on spectra with differing
51-
spectral axes.
52-
53-
Specutils version 2 implements a major change in that ``Spectrum``
54-
no longer forces the spectral axis to be last for multi-dimensional data. This
55-
was motivated by the desire for greater flexibility to allow for interoperability
56-
with other packages that may wish to use ``specutils`` classes as the basis for
57-
their own, and by the desire for consistency with the axis order that results
58-
from a simple ``astropy.io.fits.read`` of a file. The legacy behavior can be
59-
replicated by setting ``move_spectral_axis='last'`` when creating a new
60-
``Spectrum`` object. ``Spectrum`` will attempt to automatically
61-
determine which flux axis corresponds to the spectral axis during initialization
62-
based on the WCS (if provided) or the shape of the flux and spectral axis arrays,
63-
but if the spectral axis index is unable to be automatically determined you will
64-
need to specify which flux array axis is the dispersion axis with the
65-
``spectral_axis_index`` keyword. Note that since the ``spectral_axis`` can specify
66-
either bin edges or bin centers, a flux array of shape ``(10, 11)`` with spectral axis
67-
of length 10 or 11 would be ambigious. In this case you could initialize a
68-
``Spectrum`` with ``bin_specification`` set to either "edges" or "centers"
69-
to break the degeneracy.
70-
71-
An additional change for multi-dimensional spectra is that previously, initializing
72-
such a ``Spectrum`` with a ``spectral_axis`` specified, but no WCS, would
73-
create a ``Spectrum`` instance with a one-dimensional GWCS that was essentially
74-
a lookup table with the spectral axis values. In 2.0 this case will result in a GWCS with
75-
dimensionality matching that of the flux array to facilitate use with downstream packages
76-
that expect WCS dimensionality to match that of the data. The resulting spatial axes
77-
transforms are simple pixel to pixel identity operations, since no actual spatial
78-
coordinate information is available.
79-
80-
In addition to the changes to the generated GWCS, handling of input GWCS will also be
81-
improved. This mostly manifests in the full GWCS (including spatial information) being
82-
retained in the resulting ``Spectrum`` objects when reading, e.g., JWST spectral
83-
cubes.
31+
Changes in version 2.0
32+
======================
33+
34+
Specutils 2.0 has been released, see the stable docs for a summary of the changes.
35+
This version of the documentation will remain available for user of ``specutils`` 1.x.
36+
8437

8538
Getting started with :ref:`specutils <specutils>`
8639
=================================================

docs/nitpick-exceptions

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -7,7 +7,8 @@ py:obj NDUncertainty
77

88
# Links that might not work yet, depending on the astropy version
99
py:obj astropy.coordinates.SpectralQuantity
10-
py:class astropy.units.UnitBase
10+
py:class UnitBase
11+
py:class ConfigItem
1112

1213
# Classes in the SpectralCoord/SpectralQuantity methods for which we can't
1314
# control the API links.

0 commit comments

Comments
 (0)