search

Moo-Ack-Productions / bpy-build

A build sytem to make building Blender addons 10 times easier
BSD 3-Clause "New" or "Revised" License
5 stars 2 forks source link

Addition of BpyBuild API #9

Closed StandingPadAnimations closed 2 months ago

StandingPadAnimations commented 4 months ago

This PR tracks the creation of a basic API for developers to use in BpyBuild

StandingPadAnimations commented 4 months ago

@TheDuckCow this is ready for review now

StandingPadAnimations commented 4 months ago

Since BpyBuild expects certain type signatures for hooks, I've gone ahead and added typeguard as a dependency so we can check types. In the future however, I plan to move away from this dependency so we can get easier to digest errors for developers.

EDIT: while type annotations for actions are preferable, they're not required. The type checker won't throw an exception if one doesn't have type annotations (though whether that's good or not is up to the developer)

TheDuckCow commented 4 months ago

Something I can already tell I'm going to need in the context variable is the target install location. Seems like the ctx.current_path is the build folder within the git folder (at least for me), but I really need the e.g. blender 4.0 addons folder, so I can move the pre-existing MCprep_resources folder away and back after the install.

On a separate note, what's the best way to extend the ignore to skip ever copying or duplicate any files from the MCprep_resources folder? It looks like ignore_filters.main() works by having things still copied over once and then deleted after via p.unlink(), but I'm trying to avoid any copying or duplication of the resource folder.

StandingPadAnimations commented 4 months ago

Something I can already tell I'm going to need in the context variable is the target install location. Seems like the ctx.current_path is the build folder within the git folder (at least for me), but I really need the e.g. blender 4.0 addons folder, so I can move the pre-existing MCprep_resources folder away and back after the install.

This should be given in the post_install hook, so I'll see if I can get that bug resolved

On a separate note, what's the best way to extend the ignore to skip ever copying or duplicate any files from the MCprep_resources folder? It looks like ignore_filters.main() works by having things still copied over once and then deleted after via p.unlink(), but I'm trying to avoid any copying or duplication of the resource folder.

The pre_build and clean_up hooks, which sets the path to the addon source directory and is executed before BpyBuild copies the source tree and after all installs. You should be able to move files out of the addon folder in pre_build, and add them back in clean_up

TheDuckCow commented 3 months ago

Sorry I've been taking ages on this one, I need to test writing my script updates locally to see this is actually doing what I ultimately want it to, would be waste if it didn't. I'll try to get to it soon, just been swamped with too many parallel initiatives.

StandingPadAnimations commented 3 months ago

Sorry I've been taking ages on this one, I need to test writing my script updates locally to see this is actually doing what I ultimately want it to, would be waste if it didn't. I'll try to get to it soon, just been swamped with too many parallel initiatives.

No problem, the main issue at the moment is that I can't seem to recreate the issues you're facing locally. I think just to make things cleaner, BpyBuild shouldn't change the working directory and just instead pass the intended directory for the developer to use (which we already do with BabContext). It's easier to understand, and will clean up some areas of the codebase (speaking of cleaning up, at some point, I need to figure out how to clean up all the expanduser() calls we do in BpyBuild). The issue with that is that it would break backwards compatibility, but that's really a minor thing.

As an aside, I think we could also work on a proper wiki for this, but that's for future me to deal with

StandingPadAnimations commented 2 months ago

Started work on unittests as well in BpyBuild (although there are some weird areas because this is a CLI program), which should make debugging easier

TheDuckCow commented 2 months ago

Thanks for that, I keep procrastinating on this one - I'll see if I can get back to live test the baseline functionality this week

StandingPadAnimations commented 2 months ago

Glad I added build tests, because I forgot to update the test files to work without relying on working directory changes

StandingPadAnimations commented 2 months ago

@TheDuckCow I've added some extremely basic hook tests that check standard output for the correct paths, except for post_install (whose output is system dependent). Tests can be ran with python -m unittest test.tests (in a virtual environment with all the dependencies at least, I'll add a requirements.txt file as well)

EDIT: proper testing for post_install has been added in 205226d

StandingPadAnimations commented 2 months ago

I've added backwards compatibility to how the main function in actins is called. Now, if BpyBuild detects that main in an action has no arguments, it will run main with the correct working directory set (like how actions are ran in the current release of BpyBuild). This will make it easier to incrementally adopt new updates. As always, I've added a test to make sure it runs properly

TheDuckCow commented 2 months ago

Oh nice that's a super good addition, thanks for making that. I still need to get to trying this out

StandingPadAnimations commented 2 months ago

Pushed some tests that involve the MCprep source tree (mostly to make sure BpyBuild remains backwards compatible with MCprep's config). Pretty simple currently, but eventually they'll encompass everything in the MCprep build process.

StandingPadAnimations commented 2 months ago

And now I've added tests for translation builds with MCprep. One of these tests does perform a patch on an action, but that to test the new hooks feature (since MCprep currently doesn't utilize them)

StandingPadAnimations commented 2 months ago

Generally, I'm finding this to work well. I think it's probably better to move ahead, rather than me hold this up further. I had to make a minor diff in the mcprep side code to run tests for MCprep itself (just changing the cmdline call from bpy adodn build to bab).

Sounds good. I'll merge this in today and push it to PyPi on the weekend

But, one callout - I finally install poetry for the first time (don't judge too hard), and found it's giving me some errors when following the steps of the main contributing guide; I do still also think it could be nice to include the instructions for running tests, using python -m unittest discover me an error since it's not picking up the poetry env (maybe I also just need to learn that better). Still, approving in the meantime.

Found 58 errors in 8 files (checked 11 source files)
bpy-build $ poetry run mypy --pretty bpy_addon_build

For tests, you'd run poetry run python -m unittest discover, which runs Python in the environment. Alternatively, you could do poetry shell to enter the virtual environment like normally

StandingPadAnimations commented 2 months ago

By the way, if you want to learn more about Poetry, the docs are pretty comprehensive: https://python-poetry.org/docs/