commitmas / pybluedot

The Python team project for Commitmas 2016

commitmas

pybluedot's Issues

Testing?

Are we planning to write tests for the utility? If we are, I'd like to volunteer to write at least a few, because I'd like more experience writing tests.

Integration with readthedocs

• Integration with readthedocs
• Enabling local builds in the Tox configuration

Fix PEP8 Issues

#10 introduces a Tox-based framework for doing CI, but does not address the PEP8 issues shown when running tox -epep8. Someone should fix these 😄

API Bindings

Someone needs to create bindings - that is, Python code that simplifies access to, the NASA APIs.

This is a fairly large task, because there are a lot of NASA APIs, and this issue essentially encapsulates the creation of bindings for all of them.

I'd recommend that someone first start by creating some Python that other bindings can inherit from. There will be a lot of duplicate code otherwise, and we want to encourage code re-use.

Then, each NASA API should have it's own python module, and class. That way, the CLI packages can easily access these bindings, and anyone that wants to use pybluedot as a library can do so as well.

Command-line Parsing

We need to implement a module that parses command-line arguments and parameters. The base command can be something like bdot, and then after that we can put in some subcommands like bdot earth, and that will output some data about the Earth API.

We might also want some optional parameters

Configuration System

Need to implement a module that both writes the users configuration to a file (i.e. ~/.pybluedot) on initial setup, and also reads from this file.

Thinking we can implement a command like bdot init and the user will be walked through a wizard for setting up the configuration initially. It will ask for things like the API key, then write those options to a config file.

If the user tries to use any other subcommand, pybluedot will prompt them to run this init command to do the first-time setup. After that, any command should work right away

CLI command/subcommand structure.

I want to start with writing the structure for the command/subcommand for pybluedot.

My basic approach would be to make a json/dict that holds the basic information for each command/subcommand in it. It would look like:

subcommands = [
       search : {  
             name: "search",
             help: "Search the Nasa database",
             type: "string",
             options = [ 
                               {
                                 name: "--search-type",
                                 action: "store_const",
                                },
                                {
                                 name: "--limit-output",
                                 action: "store_const",
                                }
                              ] 
             function: "search_api"
        },

this object is then used to create the argparse object in a file called cli.py. I could define it strictly through argparse directly, but I think abstracting it into this structure will allow authors to add the pertinent information about their command more easily.

I think the most important part of doing it this way is documenting the format and process for using it, which I am more than willing to do.

What do we think about this approach? Can I move forward with it, or would we like to do something else?