Consider how spectra should be stored

[dr-rodriguez]

Spectra will likely point to a repository (eg, Amazon Cloud, CUNY AW). Should Astrodbkit2 resolve that into a plot-able object or should that be handled separately by the user/client?

[dr-rodriguez]

The consensus appears to be yes and to utilize the astropy specutils package to handle most of it.

[dr-rodriguez]

I'm planning to handle this by a parameter you can pass when you query the database, so for example, db.query()..astropy(spectra='spectra') would convert the column spectra into this object. A convenience method, .spectra() would be available with that set on by default but otherwise it's something users can turn on when they want real data to be downloaded/parsed.

[dr-rodriguez]

In addition to an online download, we should allow for the possibility of a locally stored file. For BDNYC, this was handled via an environment variable with the original astrodbkit code would fetch and interpret. We should still allow for this to have more dynamic storage of the files across systems.

[dr-rodriguez]

See #21 for the explicit handling of spectrum objects

[dr-rodriguez]

Also add some error handling- if a spectrum can't be loaded, it should print out a message and return the original stored text.

[dr-rodriguez]

I've added a placeholder in init for the environment variable names that will control where the spectra (and image) directories are. Currently this is ASTRODB_SPECTRA, but the use of this is not yet implemented in the spectra functions.

[dr-rodriguez]

Actually, from a quick look at the original astrodbkit, it looks like that one worked for whatever was after the $ in the name. So this may be a more general way for us to specify how the code works. It's up to each team to decide what their variable name will be.