blenderpy | Blender as a python module | Addon library
kandi X-RAY | blenderpy Summary
kandi X-RAY | blenderpy Summary
Meant for installation into a virtualenv or wherever, for unit testing of Blender extensions being authored, or developement of a Blender 3d-enabled Python application. Depends upon the bpy-build module to make sure the Blender bpy module environment is correct.
Support
Quality
Security
License
Reuse
Top functions reviewed by kandi - BETA
- Remove blender scripts
- Removes the Blender scripts directory
- Returns the path to the python script
- Return the path to blenders install
- Find the BLENDER script directory
- Prepare the build environment
- Build bpy
- Copy Blender python module to destination directory
- Install Blender scripts
- Finds the Sass scripts directory
blenderpy Key Features
blenderpy Examples and Code Snippets
Community Discussions
Trending Discussions on blenderpy
QUESTION
I maintain a Python utility that allows bpy to be installable as a Python module. Due to the hugeness of the spurce code, and the length of time it takes to download the libraries, I have chosen to provide this module as a wheel.
Unfortunately, platform differences and Blender runtime expectations makes support for this tricky at times.
Currently, one of my big goals is to get the Blender addon scripts directory to install into the correct location. The directory (simply named after the version of Blender API) has to exist in the same directory as the Python executable.
Unfortunately the way that setuptools works (or at least the way that I have it configured) the 2.79 directory is not always placed as a sibling to the Python executable. It fails on Windows platforms outside of virtual environments.
However, I noticed in setuptools documentation that you can specify eager_resources that supposedly guarantees the location of extracted files.
https://setuptools.readthedocs.io/en/latest/setuptools.html#automatic-resource-extraction https://setuptools.readthedocs.io/en/latest/pkg_resources.html#resource-extraction
There was a lot of hand waving and jargon in the documentation, and 0 examples. I'm really confused as to how to structure my setup.py file in order to guarantee the resource extraction. Currently, I just label the whole 2.79 directory as "scripts" in my setuptools Extension and ship it.
Is there a way to write my setup.py and package my module so as to guarantee the 2.79 directory's location is the same as the currently running python executable when someone runs
py -3.6.8-32 -m pip install bpy
Besides simply "hacking it in"? I was considering writing a install_requires module that would simply move it if possible but that is mangling with the user's file system and kind of hacky. However it's the route I am going to go if this proves impossible.
Here is the original issue for anyone interested.
https://github.com/TylerGubala/blenderpy/issues/13
My build process is identical to the process descsribed in my answer here
...ANSWER
Answered 2019-Sep-16 at 17:30Maybe try the data_files option of distutils/setuptools.
You could start by adding data_files=[('mydata', ['setup.py'],)], to your setuptools.setup function call. Build a wheel, then install it and see if you can find mydata/setup.py somewhere in your sys.prefix.
In your case the difficult part will be to compute the actual target directory (mydata in this example). It will depend on the platform (Linux, Windows, etc.), if it's in a virtual environment or not, if it's a global or local install (not actually feasible with wheels currently, see update below) and so on.
Finally of course, check that everything gets removed cleanly on uninstall. It's a bit unnecessary when working with virtual environments, but very important in case of a global installation.
Update
Looks like your use case requires a custom step at install time of your package (since the location of the binary for the Python interpreter relative to sys.prefix can not be known in advance). This can not be done currently with wheels. You have seen it yourself in this discussion.
Knowing this, my recommendation would be to follow the advice from Jan Vlcinsky in his comment for his answer to this question: Post install script after installing a wheel.
Add an extra
setuptoolsconsole entry point to your package (let's call itbpyconfigure).Instruct the users of your package to run it immediately after installing your package (
pip install bpy && bpyconfigure).The purpose of
bpyconfigureshould be clearly stated (in the documentation and maybe also as a notice shown in the console right after startingbpyconfigure) since it would write into locations of the file system wherepip installdoes not usually write.bpyconfigureshould figure out where is the Python interpreter, and where to write the extra data.The extra data to write should be packaged as
package_data, so that it can be found withpkg_resources.Of course
bpyconfigure --uninstallshould be available as well!
QUESTION
I am having some trouble understanding some of the basic paradigms around setuptools and am hoping to get some help understanding some of the principals and options surrounding setuptools for python.
Currently, I am working on a cross platform implementation of the blender as a python module build cycle, such that bpy.pyd/ bpy.so could be installed from pip.
I am successfully able to perform this build process from Windows. You can check out the repo here: https://github.com/TylerGubala/blenderpy
My primary concerns are as follows:
1) I have supplementary files to facilitate building for different system architectures; I want to upload these to pypi, not the built binaries
2) The supplementary files should not live inside the package when it is installed, they are only relevant during the setup/ build process
3) Currently, the way that the setup script works, is that it builds the modules, then sneakily copies the built files into the site-packages and executable directory for the given python environment. My concern here is: how, when the user runs py -m pip uninstall blenderpy will the package manager know to grab these files and remove them?
4) What is the correct way to package such a module as this?
I think my primary disconnect is coming from the fact that I would be using pypi as a build script delivery system, where the actual module that I intend to install is not present until midway through the setup.py execution.
So how could I install these utilities onto a user's machine, run them, and have my resultant built bpy.pyd be the source for my package?
Thanks in advance!
EDIT: I feel I should mention that I read through the following post and, while it seems related it seems to be talking more about 'extras' handlers and the internals of setuptools rather than talking about installing a compiled library that's controlled by python build scripts.
Python setuptools/distutils custom build for the `extra` package with Makefile
...ANSWER
Answered 2018-Jul-28 at 22:47UPDATED 28th July, 2018 for multiple improvements that I found.
I ended up finding through a lot of research and a lot of trial-and-error what I needed to do to accomplish my goal.
In the end, the solution ended up looking almost exactly like what hoefling over at this question ended up doing:
Extending setuptools extension to use CMake in setup.py?
1) Extend the setuptools.Extension class with a class of my own, which does not contain entries for the sources or libs properties
2) Extend the setuptools.commands.build_ext.build_ext class with a class of my own, which has a custom method which performs my necessary build steps (git, svn, cmake, cmake --build)
3) Extend the distutils.command.install_data.install_data class (yuck, distutils... however there doesn't seem to be a setuputils equivalent) with a class of my own, to mark the built binary libraries during setuptools' record creation (installed-files.txt) such that
- The libraries will be recorded and will be uninstalled with
pip uninstall bpy - The command
py setup.py bdist_wheelwill work natively as well, and can be used to provide precompiled versions of your source code
4) Extend the setuptools.command.install_lib.install_lib class with a class of my own, which will ensure that the built libraries are moved from their resultant build folder into the folder that setuptools expects them in (on Windows it will put the .dll files in a bin/Release folder and not where setuptools expects it)
5) Extend the setuptools.command.install_scripts.install_scripts class with a class of my own such that the scripts files are copied to the correct directory (Blender expects the 2.79 or whatever directory to be in the scripts location)
6) After the build steps are performed, copy those files into a known directory that setuptools will copy into the site-packages directory of my environment. At this point the remaining setuptools and distutils classes can take over writing the installed-files.txt record and will be fully removable!
You can check out the up to date repository here: https://github.com/TylerGubala/blenderpy
Here is a snapshot of what I ended up with:
Community Discussions, Code Snippets contain sources that include Stack Exchange Network
Vulnerabilities
No vulnerabilities reported
Install blenderpy
Support
Reuse Trending Solutions
Find, review, and download reusable Libraries, Code Snippets, Cloud APIs from over 650 million Knowledge Items
Find more librariesStay Updated
Subscribe to our newsletter for trending solutions and developer bootcamps
Share this Page
