TODO.txt

MAINTAIN

    Keep __all__ up to date with all the useful functions

    Comment and properly docstring everything

    Keep the -h following all the other common -h practices

    Make sure that the -h is up to date, including all the version info of all the external features (gcc/Cython)

    Make sure that you constantly search for the assumptions cyther makes

    Make my getIncludeAndRuntime() function is up to date with build_ext in distutils

    Any name cool badges to add? Make sure you got all the recent and useful ones
    Use http://shields.io/ to generate non changing badges

    Make sure the test_cyther.py file is updated to include the latest features (test everything!)


TO-DO (before next version)

    HELP TEXT:
        Have cyther's help text print its version!

    DEPLOYMENT:
        Figure out how to do a github release!
        Is it possible to webhook pypi into github??
        Keep an eye on Code Climate, Travis
        Follow as many conventions as possible in the bookmark 'PYPI tutorial'

    DOCS:
        Find the best format for the docstrings that is the most universal (What does sphinx use?)
            Make all documentation more readable and helpful
        Put a basic overview docstring at the beginning of each file (what is each file for?)

    TECHNICAL:
        Make cytherize and getIncludeAndRuntime shorter
            Change the name of cytherize to something more meaningful
        What is the use of the vcruntime.dll on windows installations? Does it need to be included?
        Make sure a new window doesnt get spawned on the subprocess calls (on some systems it does, some it doesnt)
        Implement the makefile system
            But for now make sure it created a file with just commands
        Get it working on Xubuntu ---> should cascade fix many other errors

    README:
        Try the automatic page generator tool for github!

        Fix the help text in the readme to not have 'Nothing here yet'
        Change the descripting of the readme so that it doesn't say that it is directly a compiler, but a processor instead
            It technically IS a compiler, but really, it weilds both compilers and ties them together
            User doesn't have to know WTF they are doing in order for it to completely work
            Offers partial compiling unlike distutils
            Dont need to know how to use distutils, instead goes simpler; How to use a makefile (tons of documentation)
            Exists because the definition of distutil's build_ext system is very weak
        Say that if there is an error, to email me the output of the '--test' option

FIX

    Theres an odd bug where "INSTALL_REQUIRES = ['cython']" will install the non-latest version of cython.

    Sometimes the warnings from gcc or cython are percieved to be errors, because they go through the same pathway.
        Can this be sorted out by regex style pattern recog??

NEW FEATURES

    I like the format of this: '------- >> begin captured stdout << --------'
        Incorporate into 'watch'

    Have the CYTHER_CONFIG_FILE hold the paths to the compiler executables!
        Then, it may be ok to not have gcc in the path, and thus a seperate and private gcc can be used

    So for this ^ we need a massive function to search through the drive as far as possible and implement regex patterns

    BUT HOW TO THE INDIVIDUAL CYTHER OPTIONS FIT INTO THE MAKEFILE SYSTEM?

    Make something like an 'instance' object to create independantly of core, THEN pass to core
        What it will do it be an object holding the attribute values of the different arg_parse flags.

    Get the arguments of run(timer=True) to work properly, or be automatic, like IPython

    Get where to find libpython!!

    Instead of the include option, have the system automatically detect the python {}.get_include() modules

    Say the search for the directories necessary for the runtime compilation fails, and returns nothing. Then run the
    crawl algorithm over the whole DRIVE to find a lib file that matches the REGEX definition

    Make cyther able to use the microsoft compiler cl; to mesh well with the windows system
        However, we need a powerful searching algorithm to find all the correct executables...

    Make the example_file.pyx a prototype for the SuperObject system. Implementing live testing of it?



LOW PRIORITY

    Erase Cyther's usage of distutils entirely

    Always back up the previous compile if there was one. Then if there is an error, don't overwrite it with anything,
    but instead, keep the backup version. Have the new compilation attempt be built in the __cythercache__ directory

########################################################################################################################

BEFORE DEPLOY (for me)

    Make sure that the version specified makes sense (major.minor.patch)

    Make sure that the README reflects the new interface changes

    Make sure that the CHANGELOG is up to date and includes the current version change

    Delete the comments that are no longer needed. Any junk or temporary commented code should be extracted

    Write a test script that actually tests the whole deal. Have it run every scenario and then
    USE the actual extension that it makes


QUESTIONS (for me to ask myself)

    Is there a better way to get the version of gcc / basic information?

    How to deal with non-standard extensions that people might be using? Don't error, but just have it print that
    it is non standard, and work anyway? What about Regex?

    Don't have args and file, have only one object with everything in it. Does this even make sense?

    Is it wise to take out the checking procedures with the getIncludeAndRuntime() function. Why are they necessary??

    Will sift ever have to return multiple results for the lib directories??

    What about lines like this platform.platform().strip().lower().startswith('windows')??
    What do the platform names even look like? Is their structure reliable? Does it need to be?

    Is it necessary to make sure that os.pardir will never be a problem??

    What about packaging the libraries with cyther?? Is cross compiling possible / a good idea?

    What is the difference between os.name and sys.platform and platform.platform?