As we're dropping 2.7x support, this is no longer needed. Most of the
compatability functions will remain though since they're more readable.

Replaced some instances of os.path with the Path object from pathlib for
readability. Also added type annotations to MCprepEnv as we're moving
towards that. This also means MCprep will not work at all in Blender
2.7x due to the use of new syntax.

This will be the first in a long process of modernizing MCprep's code
with 2.8 style code. Blender 2.7x users may not be happy, but it's for
the better. If anything, 6 years worth of 2.7x support was a mistake (in
my opinion), as it limited what we could do and opened MCprep to even
more bugs (like in Blender 2.93 with make_annotations, which ironically
now is deprecated).

Replaced the old = syntax with the new : syntax. This also removes the
need for make_annotations, hence why they're removed.

As we're removing 2.7x support, it makes sense to remove Blender
Internal compatability as the engine is not present in Blender 2.8 and
above. Even UPBGE (a fork of the Blender game engine that's still
maintained) uses EEVEE, so there's no reason to continue supporting
Blender Internal.

The bang at the top meant Linux users couldn't run the test suite. This
changes now allows Linux users to run tests

Deprecation warning function was moved in MCprepEnv since it made more
sense to put it there

Originally matprep_cycles used to take multiple arguments, each one
representing a seperate option. This was annoying as it meant the
function has an unfathomable amount of arguments to keep track of.

This has been replaced with a dataclass (called PrepOptions) that keeps
track of all the options selected by the user. Not only does it make it
slightly easier for developers, it also gives the following benefits:
	- More info on what types the different options are
	- Better organization

Previously we couldn't do this due to 2.7x support, hence this being in
mcprep-3_5-recore.

To avoid polluting output

To avoid polluting output

Dev to master for v3.4.3

I'm honestly not sure how I missed these, but good thing they were
caught. Now MCprep shouldn't be dealing with any errors related to env
now...

While removing the last of the ENVs, I noticed some deprecation warnings
regarding the use of this function, so I've went ahead and removed it.

Since this function calls other deprecated functions as well, what
should have been 1 warning was instead 3. Apologies to anyone who had to
suffer that in their terminal ;-;

In all honesty I doubt we'll get around to actually removing these
functions in 3.5.1, but since we're merging this with the 3.5 feature
branch, I think it's important to warn developers and make them think
about the eventual demise of these functions. Plus there's absolutely no
reason to use deprecated functions for 3.5 when we'll have nice features
like type annotations.

Anyway, hopefully after this commit, we'll merge this with the MCprep
3.5 feature branch *fingers crossed*

For some reason the spawner was missing the use of env, causing errors.
While this has been fixed, it does illustrate an issue with the current
deprecation system in that deprecated stuff will error out. More
investigation is needed.

This feature was requested by TheDuckCow to make dev builds easier to
create. The idea is that a file is created by the compile scripts, and
MCprep checks for the files existence to determine which flags to
enable. This makes development a lot more convinient and removes the
need for commits that change the dev flag.

This does mean the MCprepEnv class no longer has arguments, but that's
fine. In the future we might be able to read the contents of the file to
give full control over what flags to enable.

Why? It allows us to determine if we're using a dev build or not

-d allows the creation of a dev build, by adding a new file called
mcprep_dev.txt to the outputed build folder.

-f replaces the -fast option and does the fast compile mode.

When running, an error occured due to log requiring the variables
verbose and very_verbose, which do not exist until afterwards. Now it's
been moved to after those variables have been set.

The internal-rewrites branch recently gained some fixes and improvements
to the compile scripts, so I'm now merging internal-rewrites with recore
to bring those improvements to recore.

There are of course some additions made, such as type annotations (which
is a bit weird since internal-rewrites is actually now being planned for
merge in 3.5), and the use of pathlib over os, but functionaly the
features are the same.

Additionally removes all usage of the make_annotations workaround,
this commit does not affect the updater code in any way (which is
treated as a library). Preferences now draw, but mcprep scene props
are not currently registering, breaking most of the addon. Pre-existing
before this commit.

MCprep scene props still not registering, so still unable to run
automated tests.

MCprep scene props still not registering, so still unable to run
automated tests.

With this change, the UI now draws where needed. Many unit tests are
still failing.

Why? Poetry means we can easily define Python version, dependencies,
etc. without having to force developers to do everything by hand
(provided they want to use Poetry, it's fine if they don't c:).

The reason I'm doing it now is due to an upgrade on Arch Linux from
Python 3.10 to Python 3.11, breaking all virtual environments. Poetry is
useful especially on Linux where using the system Python tends to be an
annoyence.

The options I chose are based on MCprep 3.5, which mean the following:
- Blender 2.8 bpy
- Python 3.7 (as that's what 2.8 uses)

These are not set in stone, but I think those are reasonable for MCprep

The MC part was not capitalized

By removing all of the `bv28()` calls, we've gotten rid of all
deprecation warnings at startup and exit, which is awesome. Now we can
actually start live testing to find even more deprecation warnings
without having to deal with the insane output for the UI.

Previouly Linux didn't have file population for the MCprep compile
scripts, so I've went ahead and added it to make our lives easier,
especially after that time an MCprep build script made a folder called ~
that ended in my home directory being wiped

The compile scripts had some small errors (like a missing exit after cd)
but also 2 big errors: SC2308 and SC2115

https://www.shellcheck.net/wiki/SC2308
https://www.shellcheck.net/wiki/SC2115

SC2308 was due to the use of `expr substr` when checking to see if the
OS in use was Linux. According to the shellcheck wiki, this is not
portable and as such shouldn't be used. This was replaced with a pipe
expression that passes to `cut -c 1-5`

SC2115 is due to an `rm -rf "$i/$NAME/" statement, which if the variable
is not set or null, a person's system can be massively messed up. Here's
a case where due to this exact issue, the Steam client ended up deleting
everything on the root directory owned by the user:
ValveSoftware/steam-for-linux#3671

While it's great that these issues were caught ahead of time, these
should have never been in MCprep's build scripts. We already know that
MCprep's build scripts can create folders named ~, causing their own
headaches (like I dealt with a while back). We seriously need to start
enforcing shellcheck for MCprep's build scripts.

darker allows us to have automatic PEP8 formatting in changed code,
which allows us to think less about formatting and instead have it done
automatically without creating big diffs.

Of course one could argue that it's a good idea to use Black (what
darker uses under the hood), but that creates massive diffs. MCprep
already follows PEP 8 mostly but not completely, and changes would be
massive.

(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 3.5 removes 2.7x support, so we needed to update the versions
mentioned in the README to say 2.80 as the minimum version, and remove
the install steps screenshot for 2.7x

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 for developers to be aware that we now expect PEP8 formatted
code. For reasons mentioned in earlier commits, we'll be using darker
for that since it only applies formatting on changed code.

Pyenv is commonly used on Linux to avoid issues with the system python,
and can be set locally on a per folder basis. This is done with a text
file called .python-version. Since this is a per-developer thing, I'm
adding it to the gitignore

This should make virtual environment creation much easier for
developers. The file is based on the dependencies installed with Poetry,
so they're the exact same versions.

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

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

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 reverts commit 99ebce8.

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

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

This is to prevent the line from being too long

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

Ironically what was meant to be a fix ended up causing more issues... all because of incorrect syntax

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