Is your feature request related to a problem? Please describe.
While not strictly a problem, being able to display the current 5-day forecast is a staple feature in any weather checking program, in my opinion. OpenWeatherMap API provides this data -- utilize it!

Describe the solution you'd like
The forecast mode will be a separate top-level command from current. This will effectively split our operating modes in two so that each is contained separately. The OpenWeatherMap data provides 5-days worth of forecast data, at 3 hour intervals. Determine a pretty-print format, possibly with the calendar module, so that we can properly display that data. We may instead want to use a more generic table-formatting module if calendar feels limiting or does not allow us the proper control over formatting.

The end result should be the ability for the user to query a location for the 5-day forecast, with the same set of options as current would take for controlling which data to display. Output should be nicely formatted into a table, or similar structure so that it is easy to read. Ideally we want to fit our table width into a single standard terminal screen of 80x25 columns such that there should be no line breaks or broken formatting under normal circumstances.

Describe alternatives you've considered
One potential alternative is a strictly text based forecast display. Where instead of a table, you get small paragraphs or blurbs for each day in the forecast. I don't think this would translate well into final output. There would be far more data than can easily be scanned with the eye when you include 5-days at 3 hour intervals.

Additional context
The data returned by OpenWeatherMap will include a list with numbered elements for each 3-hour block. The number is cumulative as it is simply a list index, not a prediction number for each day. Therefore instead of grabbing the temperature as weather['main']['temp'], we would grab the temperature as weather[XX]['main']['temp'], where XX can be represented by day_number * hour_offset. That probably doesn't make total sense. Play with the data a bit in the REPL to help visualize how it is laid out before starting to implement our output loops.

Describe the bug
When running the current command to query current weather conditions from OpenWeatherMap it is possible for the program to fail with a KeyError when pieces of the data being expected are not present. The missing data is due to OpenWeatherMap not having data for that parameter to return. That is a perfectly normal condition and we should exit gracefully when it is encountered.

To Reproduce
This bug may not appear every time, under every condition. Takes a bit of playing around with different locations, and different flags to find a location where not all data is available. The command I have been able to consistently cause this KeyError with is:

weather current Dubai --wind

Expected behavior
Rather than not handling the error and allowing Python to throw a Traceback all over the console, we should catch the error and handle it accordingly. This may include simply omitting the data from the output, or including a warning about the parameter not being returned from the API. The user should not have to dig through a Traceback simply because OpenWeatherMap does not know the humidity, or wind speed, etc, for a given location.

Output

[$] [1] <git:(master)> .env/bin/weather current Dubai --wind
Traceback (most recent call last):
  File ".env/bin/weather", line 11, in <module>
    load_entry_point('weather', 'console_scripts', 'weather')()
  File "/home/ncdulo/dev/projects/weather_cli/.env/lib64/python3.6/site-packages/click/core.py", line 829, in __call__
    return self.main(*args, **kwargs)
  File "/home/ncdulo/dev/projects/weather_cli/.env/lib64/python3.6/site-packages/click/core.py", line 782, in main
    rv = self.invoke(ctx)
  File "/home/ncdulo/dev/projects/weather_cli/.env/lib64/python3.6/site-packages/click/core.py", line 1259, in invoke
    return _process_result(sub_ctx.command.invoke(sub_ctx))
  File "/home/ncdulo/dev/projects/weather_cli/.env/lib64/python3.6/site-packages/click/core.py", line 1066, in invoke
    return ctx.invoke(self.callback, **ctx.params)
  File "/home/ncdulo/dev/projects/weather_cli/.env/lib64/python3.6/site-packages/click/core.py", line 610, in invoke
    return callback(*args, **kwargs)
  File "/home/ncdulo/dev/projects/weather_cli/.env/lib64/python3.6/site-packages/click/decorators.py", line 21, in new_func
    return f(get_current_context(), *args, **kwargs)
  File "/home/ncdulo/dev/projects/weather_cli/cli.py", line 166, in current
    wind_cardinal = degrees_to_cardinal(weather['wind']['deg'])
KeyError: 'deg'

Desktop (please complete the following information):

• OS/Distribution: Gentoo Linux 17.1 Desktop
• Python 3.6.10
• requests-2.23.0
• click-7.1.1
• Python virtual environment? Yes

Additional context
A similar bug will manifest when the location name is not found by OpenWeatherMap. If the location name is not found, the request will still return perfectly fine. However there will be no data for us to use, and we fail with relatively the same KeyError. I am rolling this into a single bug report as error checking and handling falls under the same tree.

Describe the bug
When weather is called with a partial set of output flags, there are gaps in the --pretty output where disabled data would reside. This is not ideal. The gaps are distracting and leave us with dirty output.

To Reproduce
Call weather current with a partial set of weather output options (-C/-t/-h/-w)

Expected behavior
Display text should be adjusted to compensate for disabled flags, or missing data. When flag is disabled, the text should silently skip over that section and output like it's not even there. When flag is enabled, but the data is missing from the response, return a NaN-type value. Example:

# Temperature flag disabled, Wind flag missing data
weather current Mars --pretty long -Chw 
Current conditions for Mars are
    Light snow
      87%RH, winds NaN at NaN m/s

Compare to actual output in the next section.

Output

weather current Mars --pretty long -Ch 
Current conditions for Mars are
    Light snow at 
      87%RH, winds  at

Desktop (please complete the following information):

• OS/Distribution: Gentoo Linux 17.1 Desktop
• Python 3.6.10
• requests-2.23.0
• click-7.1.1
• Python virtual environment? Yes

Additional context
None required at this time.

Is your feature request related to a problem? Please describe.
Currently, our package is beginning to fill up. Support files, documentation, source files. All of it sitting in the top-level directory. This worked fine when it was a couple files. Now it is getting hard to manage. I don't expect it to get better on it's own either, so issue time.

Describe the solution you'd like
Using some ideas taken from guides related to Python project packaging, I would like to see weather packaged into something proper for upload to PyPi. We already have the basic framework in place, I believe. However, we will need to restructure the source directory and create a namespace for weather. This will also necessitate updating filenames, README.md instructions, setup.py, and likely other things as well.

This doesn't seem to complicated, will just require working carefully. Pay attention when doing the work. Test frequently. Ensure we don't have an issue like in another project where we committed bad files. Repeatedly.

Describe alternatives you've considered
The current organization of the repository files can be considered an alternative to the solution described above. It worked fine for just a couple files. Now it has grown unwieldy and difficult to maintain.

Additional context
No additional context required at this time.

Is your feature request related to a problem? Please describe.
Depending on how you look at it, this could be classed as a bug, or a feature (request). For now, I lean towards calling it a feature request as it is more fixing design issues with the current implementation as opposed to fixing incorrect operation.

Currently, the output string in current() is assembled through a lot of dirty string concatenation. Chaining strings together as we go through our flags. This mostly works. However, I have been running into places where I have trouble extending the code. Or having a hard time when trying to add additional --pretty formats. The current implementation does the bare minimum to just work, but nothing extra in the way of allowing for future expansion.

Describe the solution you'd like
I would like to utilize the string.Template class to handle out output format. This will allow us to build a collection of output templates, and then substitute in OpenWeatherMap data. I am wondering how best to handle the cases where certain pieces of data are missing. I think either silently skipping that parameter, or initializing it to a NaN-type value would handle it. The latter is probably preferable.

Describe alternatives you've considered
The alternative solution is to keep banging away with string concatenation and hard to maintain code. Don't do that.

Additional context
The implementation described here will require an update of the --pretty flag into an option. It will also require updating each if {conditions,temperature,...} block within the current() function so that they assign to their own variable, instead of the output string. Whether we should over-write the same variable that we test for with the output string is yet to be determined. An example being:

# This
if conditions:
    conditions = 'partly cloudy'
# Or this
if conditions:
    conditions_text = 'partly cloudy'
else:
    conditions_text = None

I tend to lean towards the latter solution, otherwise we will need to check for potential True values being given to our output template when the flag is enabled, but the data is unavailable. That is an issue I ran into before when trying a very early implementation of this feature. That attempt was not well thought through and resulted in more problems than solutions. I unfortunately did not think to save the work and simply git reset it out of existence.