Completed LEAP basic layout

.gitignore

@@ -103,3 +103,4 @@ venv.bak/
 # mypy
 .mypy_cache/
 *~
+/html/

Makefile

@@ -1,11 +1,29 @@
+BLACK        := $(shell tput -Txterm setaf 0)
+RED          := $(shell tput -Txterm setaf 1)
+GREEN        := $(shell tput -Txterm setaf 2)
+YELLOW       := $(shell tput -Txterm setaf 3)
+LIGHTPURPLE  := $(shell tput -Txterm setaf 4)
+PURPLE       := $(shell tput -Txterm setaf 5)
+BLUE         := $(shell tput -Txterm setaf 6)
+WHITE        := $(shell tput -Txterm setaf 7)
+RESET 	     := $(shell tput -Txterm sgr0)
+
 all: FORCE
-	@echo "This is an empty Makefile. You can put stuff in here, or just delete it if you don't need it."
+	@echo "\n${GREEN}This is an empty Makefile. You can put stuff in here, or just delete it if you don't need it.${RESET}\n"
+
 
 
-test: FORCE
-	echo "If you don't have pytest installed, you will need to install it globally or use 'make venv' if you want a virtualenv created with it in"
+test: FORCE message
 	py.test -v  tests/ 
 
+docs: FORCE message
+	pdoc  --html ./src/*.py --force
+
+
+message: FORCE
+	@echo "\n${RED}If you don't have pytest or pdoc3 installed, you will need to install them globally or inside a virtualenv.  This Makefile can build the venv for you, if you use 'make venv' followed by '. ./venv/bin/activate' and finally 'make prereqs'${RESET}\n"
+
+
 venv: FORCE
 	python3 -m venv venv
 

README.md

@@ -1,2 +1,66 @@
 # LEAP
-LEAP: Local Enumeration And Privesc. Framework for prohect.
+
+LEAP: Local Enumeration And Privesc. Framework for 4061CEM project.
+
+
+## What is here?
+
+Not much.
+
+This project requires you to generate most of the actual code
+yourselves.  To start with, each team should work on a fork of this
+repository together to define the common features of the individual
+pieces of functionality - we'll refer to them as "plugins". This is a
+kind of **design by contract**, which you can read about here:
+<https://www.sciencedirect.com/topics/computer-science/design-by-contract>. Some
+things to decide might be:
+  - Will each piece of functionality be in a separate file or subdirectory?
+  - Will your team have a naming convention?  For example, maybe all
+    windows enumerators will begin with "wEnum_", linux with "lEnum_"
+    and so on. 
+  - What will each function return or display? Will each function
+    print out to the user? Or will it return a block of text in a
+    string? Or a list of lines? Or maybe a dict with some meta-info
+    (version, plugin name, plugin author, date, time, etc.) and text
+    data? Or JSON? All are possibilities.
+  - Will you have a standard set of parameters to be passed in? Or can
+    each plugin have a different set of required parameters?
+  - What plugins will be implemented? Who will be the author?
+
+You should document these decisions here in the ~README.md~ file. Once
+you are all happy with this, stage, commit and push it to your shared
+fork. Then, each team member can begin writing their own tool by
+creating an individual fork. Naming your tool something sensible and
+uniquely identifiable at this point will be very helpful.  If you all
+keep the simple name "LEAP", you will find it tricky to remember which
+repository you are working on later.  You can call your own fork
+whatever you like.
+
+When the individual tools are working and each team member has their
+own plugins working, it is their responsibility to liaise with the
+other members of the team to import the other plugins.  Each team
+member should create a fork of the repositories of each of their
+team-mates, integrate their plugins and submit a pull-request for each
+fork.
+
+So, if the team members are A, B, C and D, we will have one fork to
+start with in which the team collaborates on defining the basics.
+Then A will create a personal fork of the shared repository and work
+on their tool and plugins.  When they're done, they will create forks
+from their team-mate's repositories. Let's call them LEAP-B, LEAP-C
+and LEAP-D. A will then port their plugins to each of these new forks
+and submit pull requests for them to be merged into the repositories
+of their teammates.
+
+## Why?
+
+This might seem overly complex, but it's not.  In reality, this is one
+of the common ways people collaborate using git.  You can fork any
+public project and work on your own copy without needing to ask
+permission or get added to the original repo, then if you want to
+recommend your changes to the original author you create a pull
+request and they can decide to merge it into their work or not.
+
+In this project you will be getting experience of working on a project
+and receiving multiple pull-requests from contributors and at the same
+time, contributing to the repositories of others.

requirements.txt

@@ -1 +1,2 @@
 pytest
+pdoc3

src/leap.py

@@ -1,4 +1,3 @@
-#TODO Documentation
 def dummyFunc(data):
     """ This function is a placeholder """
     import base64