(Saleman pitch time)
mcprep-build is our new, state-of-the-art build system custom made for
the MCprep project that's cross platform! Now we get less headaches
from dealing with Bash and the Windows shell as this new build system is
written in Python!

Jokes aside, this new build system is much more maintainable then the
old build system. I still need to add autopopulation, but it's 99% the
same, minus fast mode.

In the future I want to turn this into a general purpose
bpy-addon-builder sorta thing, but let's not get ahead of ourselves.

MCprep build had some issues with no arguments, so I went ahead and
fixed it since it would be annoying if we could only make dev builds of
MCprep

This is to make the documentation consistant with the actual build
system.

Co-authored-by: Patrick W. Crawford <theduckcow@live.com>

As suggested, I've added a SCRIPT_PATH variable to represent the path of
the mcprep-build script, just to make sure that all future paths are
correct. In addition, I've also removed the ADDON_DIRECTORY variable on
line 88 since it's incorrect logic (we're trying to zip a folder that
shouldn't exist)

We'll be using flake8 in MCprep build to perform PEP8 code checks to
make sure our code complies with PEP8 guidelines.

This is so we get PEP8 errors at compile time

God I love PEP8 but we got an ungodly amount of errors, and that's
ignoring W191 (Tabs instead of Spaces)

Originally the build script unzipped to the paths in
blender_installs.txt directly, but that was incorrect logic and ended
with the addons folder being polluted. This was an easy fix and I'm not
sure how it slipped from my mind.

In addition, I ran flake8 and fixed some formatting issues in the
builder.

bpy-build is a better version of mcprep-build that I'm working on. It's
more general purpose but has far better configuration. bpy-build does
work on the MCprep repo, I just need to finish some shortcommings

bpy-build now supports adding files during a build, which means we can
now use bpy-build instead of mcprep-build (if we choose to do so).

bpy-addon-build is the better version of mcprep-build (the former being
based off the latter) and will be maintained better, so it makes no
sense having a seperate build system.

bpy-addon-build has the following advantages:
	- YAML config
	- Auto-installation without blender_installs.txt
	- Ability to define actions and run them in specific cases
	- Better terminal output
	- Better argument handling

Flake8 is important for formatting checks so I've added it as a default
action to be executed during the build process

bpy-addon-build was updated to better handle missing YAML config
options, so this update is necesary

This version removes a debug statement...

Maybe I should make a proper test suite

Sorry for the large diff, that's just my formatter being annoying

This reverts commit 99ebce8.

Currently we're still deciding on Black, so I'm reverting this for now

PrepOptions is a dataclass that has a static set of options; no new
options can be added at runtime. Since that's a gurantee about the
class, we can use `__slots__` to make sure that typos in field names
generate an error. In addition, `__slots__` has a performance and memory
benefit, but that's minor compared to the development improvement that
would be gained.

Due to Blender 2.8 using Python 3.7, we have to manually add the slots
ourselves in the class definition. Hopefully in a future MCprep release
we can remove this manual declaration and use the `slots` option in the
dataclass decorator.

(Saleman pitch time)
mcprep-build is our new, state-of-the-art build system custom made for
the MCprep project that's cross platform! Now we get less headaches
from dealing with Bash and the Windows shell as this new build system is
written in Python!

Jokes aside, this new build system is much more maintainable then the
old build system. I still need to add autopopulation, but it's 99% the
same, minus fast mode.

In the future I want to turn this into a general purpose
bpy-addon-builder sorta thing, but let's not get ahead of ourselves.

Co-authored-by: Patrick W. Crawford <theduckcow@live.com>

Having issues where it's not providing the intended result, still
showing W191. Plus, Blender operator properties are not defined using
a syntax that lint checkers can parse, creating a lot of noise. We'll
need to rethink how to adopt this in the future.