Allow for country codes like en-us, listed here.
More details after #14 Merged

I'm terrible at documenting my code. Mostly because I would just rather work on functionality.

Document all functions with a docstring giving an overview of the function, and links to what portion of the file it builds on.

This is an ongoing issue

Support package.json generated by NPM, and a few other tools.

https://docs.npmjs.com/files/package.json

Now that the project gets a decent amount of contributions, I should set up a testing suite to test all of the functions.

This should be easy to do. I simply need to try a series of inputs with values that it should be able to handle.

self.image_src("htss://ddddd.com") --> fail

Allow the user to point towards a license section, like the spec: https://docs.npmjs.com/files/package.json#license

Add support for adding licence when using the -p flag.

For now the theme_color and background_color function have almost the same code, we can refactor and put those code into one global function. Something like this:

def request_color(color_type):
    ...#repeated code
    return ...

class Manifest:
    def theme_color(self):
        self.details['theme_color'] = request_color('theme_color')

    def background_color(self):
        self.details['background_color'] = request_color('background_color')

What do you think @devinmatte?

Right now everything lives inside of wasp

In reality wasp should just execute the order based on the classes defined elsewhere

Look into a way to package this project, so that the classes can be separated into separate files

Asked here: https://stackoverflow.com/questions/46366143/packaging-multiple-python-files

Maybe use this as the example of how to set this up properly: https://github.com/IGM-Software-On-Linux/584-RPM-Exercise-Py

Support generating a composer.json

Support Creating Web Manifests with all options

Allow the user to add as many related applications as they want to the array

Allow the user to point towards a contributors/author section, like the spec: https://docs.npmjs.com/files/package.json#people-fields-author-contributors

Add support for adding contributors/author when using the -p flag.

Running from package uses bin as directory

Use the format that will be created for #5 to build out a similar format for manual icon adding

Allow the user to point set a privacy setting, like the spec: https://docs.npmjs.com/files/package.json#private

Add support for adding privacy when using the -p flag.

This is the start of the discussion of a design pattern that appropriately conforms to this project goal.

A design pattern that break out of the functionality of this software in a logical manor, that can be easily maintained as we continue to build and grow the capabilities of the software.

When in the middle of a command, it would be ideal if the user could use a help command in some way.

I'd rather it not be just "help" as the entry, because then the user couldn't use that as their input, but that's also where I'm leaning. Maybe someone else has an idea as to how we would implement a step by step help command?

Right now I package for debian distributions. That's fine so far, especially because I use debian myself.

However there are a lot of users on RedHat so I should learn how to support them.

If someone has the knowledge, and wants to set this up and write up in the README how it works, and how to continue development with it, I'd heavily appreciate it.

Allow the user to point towards a repository section, like the spec: https://docs.npmjs.com/files/package.json#repository

Add support for adding repository when using the -p flag.

Try to add validation on the urls/repository type

When the user picks the name of their project, check it to see if it fits the simple name format.

Example: project-name instead of Project Name

If the user submits a name that fits the simple format, only have the single prompt, but if it's not, allow them to enter one, or have a default that formats the existing name.

Based off how package.json requires name

I want to be able to run wasp update -m -p and update the existing files without having to rewrite everything. In the run-case of wasp update it would use the existing values inside of the files, as the default, and only update the fields which are edited.

There way be some logic we can employ to make this simpler for the user.

Tagging is a feature I wanted right from the beginning. This would work in the manor of wasp tag -p -g.

What this would do, is when you go to tag in git, it will also update the version tag in package.json, debian copyright, etc.

This should be a fairly easy implementation, but we should look into making it happen.

Follow the spec for keywords: https://docs.npmjs.com/files/package.json#keywords

Add support for adding keywords when using the -p flag.

Right now all the details that are parts of the manifest, are in a Manifest class.

That works fine now, but once we start supporting more file types (package.json, composer.json, etc.) we're going to want to share that data and have users only prompted once.

Because of that we need to move away from this format. Potentially just have everything be a global function and have checks to see what's being generated. Or find a better method of handling it.

There might be a design pattern I can better apply for this specific problem

Currently the program just lets you select existing image files.
It would be really nice to allow the user to select one image, and generate multiple sizes for use.

Basically I could pass one 512x512 image and generate a series of images below that, place them somewhere smart, and add them to the manifest.

Likely would be done with Image Mavericks some way

For now the program forces user to re-input color when they enter wrong value (non-hex-color input). We should guide them. May I just go ahead and work with this @devinmatte?

Manifests allow for the addition of screenshots. Allow users to add screenshots on init just like they can add icons.

Should be modeled after the Icon subclass but following this

Find a way to validate color strings. I'm fine with limiting it to hex values during the first version if that's what it takes to get proper validation.

def theme_color(self):
    # TODO: Default
    # TODO: Validation
    self.details['theme_color'] = input("Theme Color " + str(on(["M"], args)) + ": ")

def background_color(self):
    # TODO: Default
    # TODO: Validation
    self.details['background_color'] = input("Background Color " + str(on(["M"], args)) + ": ")

Look over the JSON spec

Despite Bower being deprecated, I still would like to support it

Almost all good command line tools provide a man page for easy documentation.

Write up some documentation, that coincides with a man page so that a new user could easily pick up the tool

Right now there's the function for adding a language:

def lang(self):
    # TODO: Default
    # TODO: Validation
    self.details['lang'] = input("Language " + str(on(["M"], args)) + ": ")

I need to check it against the available languages to pick from to make sure that users can't put in invalid options.

Allow the user to point towards a bugs section, like the spec: https://docs.npmjs.com/files/package.json#bugs

Add support for adding bugs when using the -p flag.