internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: sunpy/sunpy

Issue:
Support failover to SDAC VSO endpoint
Submitted by: Cadair
From channel: #SunPy

The URL should fall back to http://sdac.virtualsolar.org/API/VSOi_rpc_literal.wsdl and the port to `'sdacVSOi'`.

This section of the `VSOClient.__init__`  https://github.com/sunpy/sunpy/blob/master/sunpy%2Fnet%2Fvso%2Fvso.py#L279 will need subsituting for some kind of connection test with fallback, probably in a method rather than inline in the `__init__`.



Discussion:
This is more complex now as that `sdac` URL is now only served over HTTPS.

https://github.com/sunpy/sunpy/pull/1916

Seems to be closed by #1916. 
This isn't actually fixed as it's waiting for an upstream fix to the VSO that @sudozer is working on.
To be clear, #1916 added the ability to do it, but we can't actually use the secondary endpoint at SDAC yet. This also required #2866 as a prerequisite to be able to connect to SDAC because of SSL, which should be tracked in #2047 
The URL to the SDAC wsdl is https://sdac.virtualsolar.org/API/VSOi_rpc_literal.wsdl , and the port is sdacVSOi.  I'm taking a look at the client to see how the new port is intended to work into the failover code.

Resolving patch:
diff --git a/sunpy/net/vso/vso.py b/sunpy/net/vso/vso.py
--- a/sunpy/net/vso/vso.py
+++ b/sunpy/net/vso/vso.py
@@ -34,7 +34,9 @@
 TIME_FORMAT = config.get("general", "time_format")
 
 DEFAULT_URL_PORT = [{'url': 'http://docs.virtualsolar.org/WSDL/VSOi_rpc_literal.wsdl',
-                     'port': 'nsoVSOi'}]
+                     'port': 'nsoVSOi'},
+                    {'url': 'https://sdac.virtualsolar.org/API/VSOi_rpc_literal.wsdl',
+                     'port': 'sdacVSOi'}]
 
 RANGE = re.compile(r'(\d+)(\s*-\s*(\d+))?(\s*([a-zA-Z]+))?')
 


Test patch:
Repository: sunpy/sunpy

Issue:
Unexpected error on import of goes module
<!-- This comments are hidden when you submit the issue so you do not need to remove them!
Please be sure to check out our contributing guidelines: https://github.com/sunpy/sunpy/blob/master/CONTRIBUTING.rst
Please be sure to check out our code of conduct:
https://github.com/sunpy/sunpy/blob/master/CODE_OF_CONDUCT.rst -->

<!-- Please have a search on our GitHub repository to see if a similar issue has already been posted.
If a similar issue is closed, have a quick look to see if you are satisfied by the resolution.
If not please go ahead and open an issue! -->

### Description
<!-- Provide a general description of the bug. -->
When importing the goes instr module to get two simple functions
```
from sunpy.instr.goes import flareclass_to_flux, flux_to_flareclass
```
I ran into an error because it was trying to import the `hek` module which requires a package I had not yet installed.

### Expected behavior
<!-- What did you expect to happen. -->
Given that the functions I wanted are simple and should not require the `hek`, I was not expecting to need to have a package installed to support the `hek` module.

### Actual behavior
<!-- What actually happened. -->
<!-- Was the output confusing or poorly described? -->
Should have no error!

I would recommend the import of `hek` is moved into the only function that uses it which is `get_goes_event_list`.


Discussion:
This is related to the discussion I want to have in #2807 I will do that in there.
I'm not getting any error here. Just warnings about the 'lightcurve' module going out of fashion. Has this been solved?
Are you sure you are using the current version from this repository? LightCurve has been deleted.  

This issue is still open and I see no reason why it would have been solved. 
I'll update and try again.
Ok ya, I get the error. I was on stable then. My bad.

Okay, I get it. It would make sense to move `import hek` into the aforementioned function. Should I do it?
Yeah, it would probably be enough. 

Resolving patch:
diff --git a/sunpy/instr/goes.py b/sunpy/instr/goes.py
--- a/sunpy/instr/goes.py
+++ b/sunpy/instr/goes.py
@@ -59,7 +59,6 @@
 from scipy.integrate import trapz, cumtrapz
 
 from sunpy import sun
-from sunpy.net import hek
 from sunpy import timeseries
 from sunpy.time import parse_time
 from sunpy.util.net import check_download_file
@@ -106,6 +105,9 @@ def get_goes_event_list(timerange, goes_class_filter=None):
         e.g. 'M1', 'X2'.
 
     """
+    # Importing hek here to avoid calling code that relies on optional dependencies.
+    from sunpy.net import hek
+
     # use HEK module to search for GOES events
     client = hek.HEKClient()
     event_type = 'FL'


Test patch:
Repository: sunpy/sunpy

Issue:
Improve our warnings in line with PEP 565
See astropy/astropy#8465


Discussion:
Hi @Cadair, I want to work on this issue. Please guide me on what changes are required to make warnings [pep 565](https://www.python.org/dev/peps/pep-0565/) compliant in sunpy. I understand that for Python < 3.7 custom warning class should derive from `FutureWarning`. Do I have to make those changes in [exceptions.py](https://github.com/sunpy/sunpy/blob/master/sunpy/util/exceptions.py)?
Also, it seems like some Astropy contributors are not in favor of making this change, what's your take on this?
Yes, they are against that and we will probably also not follow suit. At least for now. 

What we do need to do is make sure that our `SunpyDeprecationWarning` subclasses `DeprecationWarning` in the same style that `SunpyUserWarning` does. 
Thanks for clarifying @nabobalis. Does that mean I shouldn't work on this issue (because no changes are required)? 
Edit: Nevermind. I understood what needs to be done.
Well there is a one line change we need that I mentioned in my comment but otherwise, yeah this issue could be closed. 

Resolving patch:
diff --git a/sunpy/util/exceptions.py b/sunpy/util/exceptions.py
--- a/sunpy/util/exceptions.py
+++ b/sunpy/util/exceptions.py
@@ -4,6 +4,8 @@
 sunpy. Exceptions that are specific to a given subpackage should *not*
 be here, but rather in the particular subpackage.
 """
+import sys
+
 
 class SunpyWarning(Warning):
     """
@@ -19,7 +21,11 @@ class SunpyUserWarning(UserWarning, SunpyWarning):
     """
 
 
-class SunpyDeprecationWarning(SunpyWarning):
+# For PEP 565 (https://www.python.org/dev/peps/pep-0565/) compliance.
+DeprecationClass = DeprecationWarning if sys.version_info >= (3, 7) else FutureWarning
+
+
+class SunpyDeprecationWarning(DeprecationClass, SunpyWarning):
     """
     A warning class to indicate a deprecated feature.
     """


Test patch:
Repository: sunpy/sunpy

Issue:
vso.attrs.Wavelength raises AstropyDeprecationWarning
Can't work out how to fix this at the moment, so leaving a bug as a placeholder:
```python
from sunpy.net import vso
import astropy.units as u
vso.attrs.Wavelength(12 * u.AA, 16 * u.AA)
```
results in 
```
WARNING: AstropyDeprecationWarning: The truth value of a Quantity is ambiguous. In the future this will raise a ValueError. [astropy.units.quantity]
```


Discussion:

Resolving patch:
diff --git a/sunpy/net/vso/attrs.py b/sunpy/net/vso/attrs.py
--- a/sunpy/net/vso/attrs.py
+++ b/sunpy/net/vso/attrs.py
@@ -18,7 +18,6 @@
 import collections
 
 import astropy.units as u
-from astropy.time import Time
 
 from sunpy.time import TimeRange as _TimeRange
 from sunpy.net.attr import (Attr, AttrWalker, AttrAnd,
@@ -86,7 +85,7 @@ def __init__(self, wavemin, wavemax=None):
         units is valid input.
         """
 
-        if not wavemax:
+        if wavemax is None:
             wavemax = wavemin
 
         if not all(isinstance(var, u.Quantity) for var in [wavemin, wavemax]):


Test patch:
Repository: sunpy/sunpy

Issue:
Add list of constants to docs
Currently if one wants to know what constants `sunpy.sun` has built in you have to run `sunpy.sun.constants.print_all()`, but it would be nice to have a table that lists the constants here: https://docs.sunpy.org/en/latest/code_ref/sun.html#module-sunpy.sun.constants (like AstroPy: http://docs.astropy.org/en/stable/constants/index.html#reference-api)


Discussion:

Resolving patch:
diff --git a/sunpy/sun/constants.py b/sunpy/sun/constants.py
--- a/sunpy/sun/constants.py
+++ b/sunpy/sun/constants.py
@@ -89,6 +89,20 @@ def print_all():
     return t
 
 
+# Add a list of constants to the docs
+_lines = [
+    'The following constants are available:\n',
+    '====================== ============== ================ =================================',
+    '         Name              Value            Unit                 Description',
+    '====================== ============== ================ =================================',
+]
+for key, const in constants.items():
+    _lines.append('{0:^22} {1:^14.9g} {2:^16} {3}'.format(
+        key, const.value, const._unit_string, const.name))
+_lines.append(_lines[1])
+if __doc__ is not None:
+    __doc__ += '\n'.join(_lines)
+
 # Spectral class is not included in physical constants since it is not a number
 spectral_classification = 'G2V'
 au = astronomical_unit = get('mean distance')


Test patch:
Repository: sunpy/sunpy

Issue:
Sample AIA images in the gallery do not show SunPy plotting very well
The colors selected AIA images in the gallery are badly scaled.  This is probably because the data contain one or two very bright pixels which is throwing the existing scaling off.

Users going to the gallery are seeing badly scaled images, and that's not a good advertisement for SunPy.  Either the images should be changed, the default AIA scaling should be changed, or some clipping of the intensity scale should be included in the example gallery code as appropriate.


Discussion:
I want to work on this issue
@sapnamish You don't need to ask for permission to work on this issue! You can go right ahead!
is this issue still open ? i want to work on this issue. can you please guide me to the page where i can see badly scaled image ?
Hi @ravindra1307, yes this issue is still open. I assume that @wafels is referring to the `Sample Data Set Overview` gallery example. But also to a more general point that we use the sample data in many of our examples and the scaling of the AIA images might need to be looked at either within the examples or inside the AIA Map code. 
now that #3100 is merged we should modify the examples and the docs where appropriate to use that functionality to show the images with better scaling.

Resolving patch:
diff --git a/examples/acquiring_data/2011_06_07_sampledata_overview.py b/examples/acquiring_data/2011_06_07_sampledata_overview.py
--- a/examples/acquiring_data/2011_06_07_sampledata_overview.py
+++ b/examples/acquiring_data/2011_06_07_sampledata_overview.py
@@ -6,6 +6,7 @@
 An overview of the coordinated sample data set for the SOL-2011-06-07 event.
 """
 import matplotlib.pyplot as plt
+import astropy.units as u
 
 import sunpy.map
 import sunpy.timeseries
@@ -52,22 +53,22 @@
 
 fig = plt.figure(figsize=(6, 28))
 ax = fig.add_subplot(611, projection=aia_131_map)
-aia_131_map.plot()
+aia_131_map.plot(clip_interval=(0.5, 99.9)*u.percent)
 aia_131_map.draw_grid()
 ax = fig.add_subplot(612, projection=aia_171_map)
-aia_171_map.plot()
+aia_171_map.plot(clip_interval=(0.5, 99.9)*u.percent)
 aia_171_map.draw_grid()
 ax = fig.add_subplot(613, projection=aia_211_map)
-aia_211_map.plot()
+aia_211_map.plot(clip_interval=(0.5, 99.9)*u.percent)
 aia_211_map.draw_grid()
 ax = fig.add_subplot(614, projection=aia_335_map)
-aia_335_map.plot()
+aia_335_map.plot(clip_interval=(0.5, 99.9)*u.percent)
 aia_335_map.draw_grid()
 ax = fig.add_subplot(615, projection=aia_094_map)
-aia_094_map.plot()
+aia_094_map.plot(clip_interval=(0.5, 99.9)*u.percent)
 aia_094_map.draw_grid()
 ax = fig.add_subplot(616, projection=aia_1600_map)
-aia_1600_map.plot()
+aia_1600_map.plot(clip_interval=(0.5, 99.9)*u.percent)
 aia_1600_map.draw_grid()
 plt.tight_layout(pad=6.50)
 plt.show()


Test patch:
Repository: sunpy/sunpy

Issue:
1.0.0rc2: test_ts_to_array fails
When testing version 1.0.0 rc2 during build time, I see the following failure on the `test_ts_to_array` test:
```
_____________________________________ test_ts_to_array ______________________________________

generic_ts = <sunpy.timeseries.timeseriesbase.GenericTimeSeries object at 0x7fe084b4b9b0>

    def test_ts_to_array(generic_ts):
>       arr = generic_ts.to_array()

sunpy/timeseries/tests/test_timeseriesbase.py:612: 
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
sunpy/timeseries/timeseriesbase.py:576: in to_array
    return self.data.to_numpy(**kwargs)
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _

self =                      intensity
2016-10-01 05:00:00   0.000000
2016-10-01 04:59:00   0.026177
2016-10-01 04:58:00   0.0...8
2016-09-30 05:03:00  -0.078459
2016-09-30 05:02:00  -0.052336
2016-09-30 05:01:00  -0.026177

[1440 rows x 1 columns]
name = 'to_numpy'

    def __getattr__(self, name):
        """After regular attribute access, try looking up the name
        This allows simpler access to columns for interactive use.
        """
    
        # Note: obj.x will always call obj.__getattribute__('x') prior to
        # calling obj.__getattr__('x').
    
        if (name in self._internal_names_set or name in self._metadata or
                name in self._accessors):
            return object.__getattribute__(self, name)
        else:
            if self._info_axis._can_hold_identifiers_and_holds_name(name):
                return self[name]
>           return object.__getattribute__(self, name)
E           AttributeError: 'DataFrame' object has no attribute 'to_numpy'

/usr/lib/python3/dist-packages/pandas/core/generic.py:4378: AttributeError
```
Pandas: 0.23.3
Astropy: 3.1.2
Python: 3.7.3
Numpy: 1.16.2


Discussion:
Good spot, that's a pandas 0.24 call. We will patch that for rc3. Sorry about this!

Resolving patch:
diff --git a/sunpy/timeseries/timeseriesbase.py b/sunpy/timeseries/timeseriesbase.py
--- a/sunpy/timeseries/timeseriesbase.py
+++ b/sunpy/timeseries/timeseriesbase.py
@@ -567,7 +567,10 @@ def to_array(self, **kwargs):
         `~numpy.ndarray`
             If the data is heterogeneous and contains booleans or objects, the result will be of ``dtype=object``.
         """
-        return self.data.to_numpy(**kwargs)
+        if hasattr(self.data, "to_numpy"):
+            return self.data.to_numpy(**kwargs)
+        else:
+            return self.data.values
 
     def __eq__(self, other):
         """


Test patch:
Repository: sunpy/sunpy

Issue:
Frame-bias corrections may be needed for two `sunpy.coordinates.sun` functions
In `sunpy.coordinates.sun`, `true_rightascension()` and `true_declination()` when asking for J2000.0 epoch (i.e., `equinox_of_date=False` is supplied) may need to include the correction for frame bias.  Figure this out.


Discussion:
What is "frame bias" in this context?

Resolving patch:
diff --git a/sunpy/coordinates/sun.py b/sunpy/coordinates/sun.py
--- a/sunpy/coordinates/sun.py
+++ b/sunpy/coordinates/sun.py
@@ -66,7 +66,7 @@ def sky_position(t='now', equinox_of_date=True):
 
     equinox_of_date : `bool`
         If True, output is referred to the true equinox of date.  Otherwise, output is referred to
-        the J2000.0 epoch.
+        the J2000.0 epoch (ICRF orientation, not dynamical orientation).
     """
     ra = apparent_rightascension(t, equinox_of_date=equinox_of_date)
     dec = apparent_declination(t, equinox_of_date=equinox_of_date)
@@ -231,7 +231,7 @@ def true_rightascension(t='now', equinox_of_date=True):
 
     equinox_of_date : `bool`
         If True, output is referred to the mean equinox of date.  Otherwise, output is referred to
-        the J2000.0 epoch.
+        the J2000.0 epoch (ICRF orientation, not dynamical orientation).
     """
     if equinox_of_date:
         # Mean equinox of date
@@ -267,7 +267,7 @@ def true_declination(t='now', equinox_of_date=True):
 
     equinox_of_date : `bool`
         If True, output is referred to the mean equinox of date.  Otherwise, output is referred to
-        the J2000.0 epoch.
+        the J2000.0 epoch (ICRF orientation, not dynamical orientation).
     """
     if equinox_of_date:
         # Mean equinox of date
@@ -323,7 +323,7 @@ def apparent_rightascension(t='now', equinox_of_date=True):
 
     equinox_of_date : `bool`
         If True, output is referred to the true equinox of date.  Otherwise, output is referred to
-        the J2000.0 epoch.
+        the J2000.0 epoch (ICRF orientation, not dynamical orientation).
     """
     if equinox_of_date:
         # True equinox of date
@@ -356,7 +356,7 @@ def apparent_declination(t='now', equinox_of_date=True):
 
     equinox_of_date : `bool`
         If True, output is referred to the true equinox of date.  Otherwise, output is referred to
-        the J2000.0 epoch.
+        the J2000.0 epoch (ICRF orientation, not dynamical orientation).
     """
     if equinox_of_date:
         # True equinox of date


Test patch:
Repository: sunpy/sunpy

Issue:
Lat and Lon the wrong way around when put into fitshe`sunpy.map.make_fitswcs_header`
# Description
I think its a bug in the `make_fitswcs_header` here https://github.com/sunpy/sunpy/blob/master/sunpy/map/header_helper.py#L134

The x and y values of the input SkyCoord (i.e. lon and lat) are put into the fits header as 
crval1 = lat and crval2 = lon - shouldn't it be the other way around? 

For example:
```
import sunpy.map
from sunpy.coordinates import frames
from sunpy.time import parse_time
from astropy.coordinates import SkyCoord
from astropy import units


coord1 = SkyCoord(1000*u.arcsec, 0*u.arcsec, observer = 'earth', 
                  obstime = parse_time('now'), frame = frames.Helioprojective)
data = data1 = np.zeros((4096, 4096))
map_header = sunpy.map.make_fitswcs_header(data, coord1)
my_map = sunpy.map.Map(data, map_header)
my_map.peek(draw_limb=True)

```


![image](https://user-images.githubusercontent.com/4620298/65614232-469f4c00-df85-11e9-9135-f28fee7720e2.png)


Given that the reference coordinate of the center pixel should be (1000, 0) rather than (0, 1000) as shown. 

This is an easy fix - does this make sense or am I missing something?


Discussion:

Resolving patch:
diff --git a/sunpy/map/header_helper.py b/sunpy/map/header_helper.py
--- a/sunpy/map/header_helper.py
+++ b/sunpy/map/header_helper.py
@@ -131,8 +131,8 @@ def make_fitswcs_header(data, coordinate,
     if scale is None:
         scale = [1., 1.] * (u.arcsec/u.pixel)
 
-    meta_wcs['crval1'], meta_wcs['crval2'] = (coordinate.spherical.lat.to_value(meta_wcs['cunit1']),
-                                              coordinate.spherical.lon.to_value(meta_wcs['cunit2']))
+    meta_wcs['crval1'], meta_wcs['crval2'] = (coordinate.spherical.lon.to_value(meta_wcs['cunit1']),
+                                              coordinate.spherical.lat.to_value(meta_wcs['cunit2']))
 
     meta_wcs['crpix1'], meta_wcs['crpix2'] = (reference_pixel[0].to_value(u.pixel),
                                               reference_pixel[1].to_value(u.pixel))


Test patch:
diff --git a/sunpy/map/tests/test_header_helper.py b/sunpy/map/tests/test_header_helper.py
--- a/sunpy/map/tests/test_header_helper.py
+++ b/sunpy/map/tests/test_header_helper.py
@@ -148,3 +148,14 @@ def test_HGS_CAR_header():
     # the center of the array.
     assert u.allclose(world_coords.lon, world_coords.lon[::-1, ::-1]*-1)
     assert u.allclose(world_coords.lat, world_coords.lat[::-1, ::-1]*-1)
+
+
+def test_latlon_order():
+    # This tests that CRVAL1, CRVAL2 (i.e. lon,lat) correspond to CTYPE1, CTYPE2 (i.e. HGLN, HGLT)
+    data = np.zeros((100, 100))
+    coord = SkyCoord(20*u.arcsec, -10*u.arcsec, obstime='2013-10-28', frame=frames.Helioprojective)
+    header = sunpy.map.make_fitswcs_header(data, coord)
+    # check LON
+    assert ('LN' in header['ctype1']) and header['crval1'] == coord.spherical.lon.to_value()
+    # check LAT
+    assert 'LT' in header['ctype2'] and header['crval2'] == coord.spherical.lat.to_value()
Repository: sunpy/sunpy

Issue:
Import matplotlib only in plot methods
Currently `from sunpy import timeseries` requires a working Matplotlib installation; it would be nice if it was possible to use the `TimeSeries` object without needing a full on Matplotlib installation.

Relevant line:
```python
  File "/Users/dstansby/miniconda3/envs/helios-alphas/lib/python3.7/site-packages/sunpy/timeseries/timeseriesbase.py", line 15, in <module>
    import matplotlib.pyplot as plt
```


#3376 did this for timeseries, we need to do it for map as well, and change `setup.cfg`.


Discussion:
I wonder if there are any other places we can do this for. 
We have discussed this at various points in the past, but am happy to discuss it again.

Where I remember the discussion ending up is we considered the ability to display themselves pretty fundamental to the base data types, so we didn't do anything to address this. This question is certainly larger than just timeseries, we either do it for all of them or none of them.
Did any potential downsides come up? (other than someone has to spend the time doing the refactoring). My current use case is importing some timeseries data with units (to a `TimeSeries`), doing some processing, then saving the result to file.
I can't really remember to be honest, it was a long time ago.
I suppose if we moved the imports into the methods but kept the dependency specifications the same it wouldn't really change any behaviour.
I would be up for that. 
That kind of becomes a larger stylistic choice for our code base. I.e. move all optional dependancies imports into the functions that use them? a-la astropy?

Where do we draw the line with that? What is "non-optional"? everything outside of `numpy` and `astropy`?
Personally I'd say `numpy` and `astropy` should be considered required for everything, and then I guess other dependencies can be decided on a module by module level? Maybe a nice table in the docs with packages and their dependencies is what is needed eventually.

Resolving patch:
diff --git a/sunpy/timeseries/timeseriesbase.py b/sunpy/timeseries/timeseriesbase.py
--- a/sunpy/timeseries/timeseriesbase.py
+++ b/sunpy/timeseries/timeseriesbase.py
@@ -6,8 +6,6 @@
 import warnings
 from collections import OrderedDict
 
-import matplotlib as mpl
-import matplotlib.pyplot as plt
 import pandas as pd
 
 import astropy
@@ -418,6 +416,7 @@ def plot(self, axes=None, **plot_args):
         axes : `~matplotlib.axes.Axes`
             The plot axes.
         """
+        import matplotlib.pyplot as plt
         # Get current axes
         if axes is None:
             axes = plt.gca()
@@ -438,6 +437,7 @@ def peek(self, **kwargs):
         **kwargs : `dict`
             Any additional plot arguments that should be used when plotting.
         """
+        import matplotlib.pyplot as plt
         # Check we have a timeseries valid for plotting
         self._validate_data_for_ploting()
 


Test patch: