Improve support for building Blender as a Python Module (WITH_PYTHON_MODULE) #100913

New Issue

Campbell Barton · 2022-09-08T13:00:39+02:00

Campbell Barton commented

2022-09-08 13:00:39 +02:00

Proposal

This task is to gather TODO's, tasks related to making building Blender as a Python module better (& officially) supported.

Motivation

The current status of the bpy module WITH_PYTHON_MODULE being an unofficially supported built option isn't ideal.

If developers attempt to use this and it fails, we can tell them that they're on their own... although sometimes they manage to get help from others.

From meeting with the bf-admins recently we discussed either dropping support for this entirely, or improving support.
The general agreement was that this is useful (scientific visualization, integrating Blender with existing Python setup on remote servers ... etc).

TODO

Update WIKI Page *Note that WITH_PYTHON_MODULE is officially supported.//

Possible Changes

Consider including setup.py with Blender (needs to be investigated, perhaps postpone until the status of the pip package has been established). See: D9230: Blender as a Python Module - Extension Module Packaging Script.

Open Topics

Distributing pre-compiled builds: Would blender.org distribute the module (download page etc). or would we accept this being available only via pip for e.g.

To update the existing `bpy` pip package, it would be simpler if we were the package owners, see: [[ https://github.com/pypa/pypi-support/issues/2231 | this ticket ]].

What level of support exactly would be provide (bugs that interact with other Python modules can be quite involved). Suggest we only resolve errors that are obviously errors in Blender's code.
The bpy module might be integrated into tests (at least basic tests it's working as expected, it need not run the full test suit).

Out of Scope

Distributing it along side official blender releases. Possible, but doesn't seem so valuable, especially as users would need to manually move files about to integrate it with their existing Python environment.

Progress

Listing recent progress that improves support for running Blender as a Python module.

Improve installation, installed bpy.so and versioned data-files directory (e.g 3.4) is copied directly into site-packages, now resolved (81558783e4).
GPU rendering (EEVEE/WorkBench) is now supported (3195a38120).
5e2d139ee3
8a9d1f19ab
f7a4ede79f
2c23b4e0bf
9189260880
060da0858b
7bd60d40ef
d26220d97a
260b75a952 Python API documentation for Blender as a Python Module
9f76d0c8e6

Other Remarks

This may not be a large change in practice, for the moment this is more a matter of messaging/communication, although it does mean there is pressure to keep this working on all supported platforms.
Added platform maintainers as subscribers, besides Python this mostly impacts platform maintainers.

### Proposal This task is to gather TODO's, tasks related to making building Blender as a Python module better (& officially) supported. ### Motivation The current status of the `bpy` module `WITH_PYTHON_MODULE` being an unofficially supported built option isn't ideal. If developers attempt to use this and it fails, we can tell them that they're on their own... although sometimes they manage to get help from others. From meeting with the bf-admins recently we discussed either dropping support for this entirely, or improving support. The general agreement was that this is useful (scientific visualization, integrating Blender with existing Python setup on remote servers ... etc). ### TODO - Update [WIKI Page ](https:*wiki.blender.org/wiki/Building_Blender/Other/BlenderAsPyModule)*Note that `WITH_PYTHON_MODULE` is officially supported.// ### Possible Changes - Consider including `setup.py` with Blender (needs to be investigated, perhaps postpone until the status of the `pip` package has been established). See: [D9230: Blender as a Python Module - Extension Module Packaging Script](https://archive.blender.org/developer/D9230). ### Open Topics - Distributing pre-compiled builds: Would blender.org distribute the module (download page etc). or would we accept this being available only via `pip` for e.g. ``` To update the existing `bpy` pip package, it would be simpler if we were the package owners, see: [[ https://github.com/pypa/pypi-support/issues/2231 | this ticket ]]. ``` - What level of support exactly would be provide (bugs that interact with other Python modules can be quite involved). Suggest we only resolve errors that are obviously errors in Blender's code. - The `bpy` module might be integrated into tests (at least basic tests it's working as expected, it need not run the full test suit). ### Out of Scope - Distributing it along side official blender releases. Possible, but doesn't seem so valuable, especially as users would need to manually move files about to integrate it with their existing Python environment. ---- ### Progress Listing recent progress that improves support for running Blender as a Python module. - Improve installation, installed `bpy.so` and versioned data-files directory (e.g `3.4`) is copied directly into `site-packages`, now resolved (81558783e4). - GPU rendering (EEVEE/WorkBench) is now supported (3195a38120). - 5e2d139ee3 - 8a9d1f19ab - f7a4ede79f - 2c23b4e0bf - 9189260880 - 060da0858b - 7bd60d40ef - d26220d97a - 260b75a952 [Python API documentation for Blender as a Python Module ](https://docs.blender.org/api/3.4/info_advanced_blender_as_bpy.html) - 9f76d0c8e6 ### Other Remarks - This may not be a large change in practice, for the moment this is more a matter of messaging/communication, although it does mean there is pressure to keep this working on all supported platforms. - Added platform maintainers as subscribers, besides Python this mostly impacts platform maintainers.

Campbell Barton self-assigned this 2022-09-08 13:00:39 +02:00

Campbell Barton commented

2022-09-08 13:00:39 +02:00

Added subscriber: @ideasman42

Campbell Barton commented

2022-09-08 13:03:01 +02:00

Added subscribers: @LazyDodo, @brecht, @dr.sybren, @mont29

Pratik Borhade commented

2022-09-08 14:12:12 +02:00

Added subscriber: @PratikPB2123

Stephen Imhoff commented

2022-09-08 23:38:52 +02:00

Added subscriber: @Clockwork-Muse

Stephen Imhoff commented

2022-09-08 23:38:52 +02:00

As I mentioned in one of my previous issues, you can get a pre-compiled wheel that does the "right thing" almost trivially; I have a sample stub project that builds blender and packages the wheel .
Notes on that sample;

I've only tested that on Linux (get a build + wheel via pip wheel . from the root of that directory, assuming blender/dependencies are available in /blender_wheel/blender and /blender_wheel/lib). I can't test on Mac, and Windows did something strange when I tried. I need to work on the full set of steps (was run from a manylinux image, for instance).
Given the way scikit-build/python packaging works, it currently requires a "Wrapper" module; external scripts must import blenderpy. This can be worked around by patching/flagging the module name in blender during build. I'd recommend this to make it easier to transfer scripts.
The current bpy module is very different than a blender release. For instance, it doesn't include CUDA/etc support (Cycles would be constrained to the CPU), bullet isn't included... which makes it unusable for some scenarios. I've been debating packaging/distributing blender myself, and I'd actually use the release config and only specify the minimum flags required (-DWITH_PYTHON_MODULE=ON, -DWITH_INSTALL_PORTABLE=ON, -DWITH_MEM_JEMALLOC=OFF, maybe one or two more?)

From personal experience, running as a module sometimes seems to just fail due to unclear context differences, up to and including segfaults. For instance (I need to post the repro for this...), if a mesh has a subdivision node below a geometry node and the subdivision node is applied, the desktop version succeeds, but segfaults in the module. Operators can be chancy - I can't get object duplication to occur (bpy.ops.object.duplicate_move_linked() - Alt + D); no error, just objects aren't duplicated/linked/something.

That said, having python as a module makes integrating/using it as "just another package" so much simpler, especially since installing packages into blender is non-trivial (including things like not having an easy way to set up environments).

Would blender.org distribute the module (download page etc).

PyPi doesn't currently easily support nightly builds (specifically, ageing them out). Nightlies might have to be something the project distributes, at least in the short term.

As I mentioned in one of my previous issues, you can get a pre-compiled wheel that does the "right thing" almost trivially; I have a [sample stub project that builds blender and packages the wheel ](https://github.com/Clockwork-Muse/bpy/tree/scikit-build). Notes on that sample; - I've only tested that on Linux (get a build + wheel via `pip wheel .` from the root of that directory, assuming blender/dependencies are available in `/blender_wheel/blender` and `/blender_wheel/lib`). I can't test on Mac, and Windows did something strange when I tried. I need to work on the full set of steps (was run from a manylinux image, for instance). - Given the way scikit-build/python packaging works, it currently requires a "Wrapper" module; external scripts must `import blenderpy`. This can be worked around by patching/flagging the module name in blender during build. I'd recommend this to make it easier to transfer scripts. - The current bpy module is very different than a blender release. For instance, it doesn't include CUDA/etc support (Cycles would be constrained to the CPU), bullet isn't included... which makes it unusable for some scenarios. I've been debating packaging/distributing blender myself, and I'd actually use the `release` config and only specify the minimum flags required (`-DWITH_PYTHON_MODULE=ON`, `-DWITH_INSTALL_PORTABLE=ON`, `-DWITH_MEM_JEMALLOC=OFF`, maybe one or two more?) From personal experience, running as a module sometimes seems to just fail due to unclear context differences, up to and including segfaults. For instance (I need to post the repro for this...), if a mesh has a subdivision node below a geometry node and the subdivision node is applied, the desktop version succeeds, but segfaults in the module. Operators can be chancy - I can't get object duplication to occur (`bpy.ops.object.duplicate_move_linked()` - `Alt + D`); no error, just objects aren't duplicated/linked/something. That said, having python as a module makes integrating/using it as "just another package" so much simpler, especially since installing packages into blender is non-trivial (including things like not having an easy way to set up environments). > Would blender.org distribute the module (download page etc). [PyPi doesn't currently easily support nightly builds (specifically, ageing them out). ](https://github.com/pypi/warehouse/issues/8792) Nightlies might have to be something the project distributes, at least in the short term.

blender-admin commented

2022-09-09 03:12:56 +02:00

This issue was referenced by 2c23b4e0bf

This issue was referenced by 2c23b4e0bff0ddd7219f4d23bcbe95d2da921fed

Campbell Barton commented

2022-09-09 07:54:26 +02:00

@Clockwork-Muse thanks for your feedback.

Issues relating to PIP / wheel's ... I don't have strong opinions on, it's more a question of what level of support benefits users, how much work is this to support etc. The current "bpy" module in pip looks to be outdated. If anyone is interested to improve the state of the affairs, it would be good to know. For the time being simply improving support and making sure it's working well (when compiled locally) is a start.
Regarding running into problems with the module, from my experience nearly all of these kinds of problems also exist when running Blender in background mode, if there are crashes - those should be reported.

As for operators not working (also an issue in background mode), that's more involved as many operators depend on active 3D viewport for e.g. which doesn't exist in background mode. Even then, support for some operators can be improved. If a list were collected of high-priority operate is to support in background mode, then we could check on supporting those.

@Clockwork-Muse thanks for your feedback. - Issues relating to PIP / wheel's ... I don't have strong opinions on, it's more a question of what level of support benefits users, how much work is this to support etc. The current "bpy" module in pip looks to be outdated. If anyone is interested to improve the state of the affairs, it would be good to know. For the time being simply improving support and making sure it's working well (when compiled locally) is a start. - Regarding running into problems with the module, from my experience nearly all of these kinds of problems also exist when running Blender in background mode, if there are crashes - those should be reported. ``` As for operators not working (also an issue in background mode), that's more involved as many operators depend on active 3D viewport for e.g. which doesn't exist in background mode. Even then, support for some operators can be improved. If a list were collected of high-priority operate is to support in background mode, then we could check on supporting those. ```

Raimund Klink commented

2022-09-09 12:07:25 +02:00

Added subscriber: @Raimund58

Stephen Imhoff commented

2022-09-09 17:03:36 +02:00

Added subscriber: @TylerGubala

Stephen Imhoff commented

2022-09-09 17:03:36 +02:00

The current "bpy" module in pip looks to be outdated.

... and isn't pre-built (only a couple of wheels), and doesn't have gpu support (that's a different package or two), and maybe not documentation/code completion (native modules don't always work correctly with code completion due to security concerns - opencv has this issue, for instance), and last I knew required a different "root" package, as mentioned.
It's unclear whether the author would be up to the foundation taking over that package.... summoning. @TylerGubala

That said, I wouldn't mind working on the final build script, if I can get some direction around dependencies and some other choices;

Building with GPU support ends up requiring that GPU/display libraries be installed on the host (eg, libGL on linux). This isn't an issue for desktop environments, but may be for certain server scenarios. Since at least my use case is server rendering, would it be better to distribute a single package that always requires these libraries to function, or to split them for GPU/no-GPU scenarios? (It's also possible blender could be modified to not load those libraries until they're actually required, but that's beyond my abilities)
I've previously tried to figure out what other packages are installed into the buildbot environment/how they're installed into the environment for my own (internal) packaging script, but haven't been able to find the relevant scripts. This would be necessary for any cuda/optix/etc support, plus maybe a few other packages. Note these aren't part of the pre-built dependencies.
Ideally the package would build and distribute wheels, ideally via the official ci scripts . This appears to require a different CI setup than is currently used for the main blender build; no support for phabricator, although I don't know what the CI setup is going to be with the move to Gitea.

> The current "bpy" module in pip looks to be outdated. ... and isn't pre-built (only a couple of wheels), and doesn't have gpu support (that's a different package or two), and maybe not documentation/code completion (native modules don't always work correctly with code completion due to security concerns - opencv has this issue, for instance), and last I knew required a different "root" package, as mentioned. It's unclear whether the author would be up to the foundation taking over that package.... summoning. @TylerGubala That said, I wouldn't mind working on the final build script, if I can get some direction around dependencies and some other choices; - Building with GPU support ends up requiring that GPU/display libraries be installed on the host (eg, libGL on linux). This isn't an issue for desktop environments, but may be for certain server scenarios. Since at least my use case is server rendering, would it be better to distribute a single package that always requires these libraries to function, or to split them for GPU/no-GPU scenarios? (It's also possible blender could be modified to not load those libraries until they're actually required, but that's beyond my abilities) - I've previously tried to figure out what other packages are installed into the buildbot environment/how they're installed into the environment for my own (internal) packaging script, but haven't been able to find the relevant scripts. This would be necessary for any cuda/optix/etc support, plus maybe a few other packages. Note these aren't part of the pre-built dependencies. - Ideally the package would build and distribute wheels, ideally via [the official ci scripts ](https://github.com/pypa/cibuildwheel). This appears to require a different CI setup than is currently used for the main blender build; no support for phabricator, although I don't know what the CI setup is going to be with the move to Gitea.

Brecht Van Lommel commented

2022-09-09 18:39:22 +02:00

After D15291 we actually have no hard dependency on libGL and only load it at runtime when needed. Headless rendering is now possible through EGL.

If we were to officially maintain such a package as part of the Blender project, we would most likely build it on our own buildbot infrastructure instead of using cibuildwheel, and do it for one or maybe two Python versions.

So I think any build script would not need to actually build Blender or care about its dependencies. We'd need a script to package a bpy folder that's already complete into a wheel, and eventually also automates uploading it to pypi.

After [D15291](https://archive.blender.org/developer/D15291) we actually have no hard dependency on libGL and only load it at runtime when needed. Headless rendering is now possible through EGL. If we were to officially maintain such a package as part of the Blender project, we would most likely build it on our own buildbot infrastructure instead of using `cibuildwheel`, and do it for one or maybe two Python versions. So I think any build script would not need to actually build Blender or care about its dependencies. We'd need a script to package a `bpy` folder that's already complete into a wheel, and eventually also automates uploading it to pypi.

Stephen Imhoff commented

2022-09-09 22:55:28 +02:00

After D15291 we actually have no hard dependency on libGL and only load it at runtime when needed. Headless rendering is now possible through EGL.

Okay, previously the dependency existed, that's good to know.

If we were to officially maintain such a package as part of the Blender project, we would most likely build it on our own buildbot infrastructure instead of using cibuildwheel, and do it for one or maybe two Python versions.

My plan/recommendation would be to pin the wheel version to the version of python that gets usually gets distributed with that version of blender. I'd previously planned to backport some of the changes to 3.0.0 (at least in a fork) to widen the python versions available, but that's likely not hugely necessary.
That aside, building especially a manylinux wheel is not necessarily a trivial task, as there are strict limitations around versioning of libc and the compiler toolset, among other things. I don't know enough about the blender release build process (or what goes into the wheel builders) to know how those limitations would play out. Still, it looks like most of it is run as a pip package, so may run on existing infra anyways (even if not officially supported).

We'd need a script to package a bpy folder that's already complete into a wheel

This is also rather trivial - I've previously written a version of the script that does this - I'm just more concerned with what flags have been turned off/on. My own use case includes things like server-based GPU rendering and physics simulations neither of which are enabled in the existing bpy build target. I think most people are going to want an "as close to desktop as possible" package - it's a little prohibitive to reduce/bake meshes if cycles is running on the CPU...

>After [D15291](https://archive.blender.org/developer/D15291) we actually have no hard dependency on libGL and only load it at runtime when needed. Headless rendering is now possible through EGL. Okay, *previously* the dependency existed, that's good to know. > If we were to officially maintain such a package as part of the Blender project, we would most likely build it on our own buildbot infrastructure instead of using `cibuildwheel`, and do it for one or maybe two Python versions. My plan/recommendation would be to pin the wheel version to the version of python that gets usually gets distributed with that version of blender. I'd previously planned to backport some of the changes to 3.0.0 (at least in a fork) to widen the python versions available, but that's likely not hugely necessary. That aside, building especially a manylinux wheel is not necessarily a trivial task, as there are strict limitations around versioning of libc and the compiler toolset, among other things. I don't know enough about the blender release build process (or what goes into the wheel builders) to know how those limitations would play out. Still, it looks like most of it is run as a pip package, so may run on existing infra anyways (even if not officially supported). > We'd need a script to package a `bpy` folder that's already complete into a wheel This is also rather trivial - I've previously written a version of the script that does this - I'm just more concerned with what flags have been turned off/on. My own use case includes things like server-based GPU rendering and physics simulations **neither of which** are enabled in the existing `bpy` build target. I think most people are going to want an "as close to desktop as possible" package - it's a little prohibitive to reduce/bake meshes if cycles is running on the CPU...

Brecht Van Lommel commented

2022-09-10 02:24:55 +02:00

That aside, building especially a manylinux wheel is not necessarily a trivial task, as there are strict limitations around versioning of libc and the compiler toolset, among other things.

Blender releases are already built to run on many Linux distribution versions. The bpy module would have the same minimum requirements as Blender (glibc 2.17 this year, glibc 2.28 next year). To be able to use the same precompiled libraries and buildbot infrastructure.

I'm just more concerned with what flags have been turned off/on. My own use case includes things like server-based GPU rendering and physics simulations neither of which are enabled in the existing bpy build target.

Indeed it seems the current configuration turns off a lot of options. For an official bpy package I think we should use blender_release.cmake as a base, and keep features like GPU rendering, Alembic, OpenVDB and Bullet enabled.

> That aside, building especially a manylinux wheel is not necessarily a trivial task, as there are strict limitations around versioning of libc and the compiler toolset, among other things. Blender releases are already built to run on many Linux distribution versions. The bpy module would have the same minimum requirements as Blender (glibc 2.17 this year, glibc 2.28 next year). To be able to use the same precompiled libraries and buildbot infrastructure. > I'm just more concerned with what flags have been turned off/on. My own use case includes things like server-based GPU rendering and physics simulations neither of which are enabled in the existing bpy build target. Indeed it seems the current configuration turns off a lot of options. For an official bpy package I think we should use `blender_release.cmake` as a base, and keep features like GPU rendering, Alembic, OpenVDB and Bullet enabled.

Brecht Van Lommel commented

2022-09-10 13:53:20 +02:00

Changed status from 'Needs Triage' to: 'Confirmed'

Stephen Imhoff commented

2022-09-13 05:04:24 +02:00

A while back, I proposed switching to the cmake FindPython module in D14954. Would that be appropriate to consider as part of the other changes here as well? VFX reference platform is moving to glibc 2.28, which implies an upgrade to CentOS 8/AlmaLinux 8 (where cmake 3.20 is available in the default repositories).

So I think any build script would not need to actually build Blender or care about its dependencies. We'd need a script to package a bpy folder that's already complete into a wheel, and eventually also automates uploading it to pypi.

I thought I had a trivial permanent script that would do this solely with a pyproject.toml/setup.cfg, but it isn't working now. I know I have a working version that abuses package_data and runs from setup.py... but I want to revisit this.

Why is the requirement that we package the pre-built directory, as opposed to building via scikit-build/pip wheel? We already need to do a separate build when we call make bpy (or make release with the option changes), so there isn't extra work required in that sense, and building via pip wheel is far cleaner.
Building a native python wheel is simpler and easier when python initiates the build, and becomes more important as python transitions to the modern pyproject.toml build definitions, and away from setup.py. The existing python tooling does not like to wrap an externally built library, and the situation is actually going to get worse as the buildsystem modernizes (it was doable by messing around with distutils, but that's officially deprecated).

A while back, I proposed switching to the cmake `FindPython` module in [D14954](https://archive.blender.org/developer/D14954). Would that be appropriate to consider as part of the other changes here as well? VFX reference platform is moving to glibc 2.28, which implies an upgrade to CentOS 8/AlmaLinux 8 (where cmake 3.20 is available in the default repositories). > So I think any build script would not need to actually build Blender or care about its dependencies. We'd need a script to package a `bpy` folder that's already complete into a wheel, and eventually also automates uploading it to pypi. I *thought* I had a trivial permanent script that would do this solely with a `pyproject.toml`/`setup.cfg`, but it isn't working now. I know I have a working version that abuses `package_data` and runs from `setup.py`... but I want to revisit this. Why is the requirement that we package the pre-built directory, as opposed to building via scikit-build/`pip wheel`? We **already** need to do a separate build when we call `make bpy` (or `make release` with the option changes), so there isn't extra work required in that sense, and building via `pip wheel` is far cleaner. Building a native python wheel is simpler and easier when python initiates the build, and becomes more important as python transitions to the modern `pyproject.toml` build definitions, and away from `setup.py`. The existing python tooling does *not* like to wrap an externally built library, and the situation is actually going to get worse as the buildsystem modernizes (it was doable by messing around with `distutils`, but that's officially deprecated).

Campbell Barton commented

2022-09-13 06:40:23 +02:00

@Clockwork-Muse I don't think building Blender as a Python module impacts the decision on D14954.
Unless there is something that patch fixes that we can't easily fix in our own Python finding script.

In #100913#1416104, @Clockwork-Muse wrote:
A while back, I proposed switching to the cmake FindPython module in D14954. Would that be appropriate to consider as part of the other changes here as well? VFX reference platform is moving to glibc 2.28, which implies an upgrade to CentOS 8/AlmaLinux 8 (where cmake 3.20 is available in the default repositories).

So I think any build script would not need to actually build Blender or care about its dependencies. We'd need a script to package a bpy folder that's already complete into a wheel, and eventually also automates uploading it to pypi.

I thought I had a trivial permanent script that would do this solely with a pyproject.toml/setup.cfg, but it isn't working now. I know I have a working version that abuses package_data and runs from setup.py... but I want to revisit this.

Why is the requirement that we package the pre-built directory, as opposed to building via scikit-build/pip wheel? We already need to do a separate build when we call make bpy (or make release with the option changes), so there isn't extra work required in that sense, and building via pip wheel is far cleaner.

(answering for myself) while I wouldn't consider it a hard requirement - whatever solution is used should minimize any duplicate work regarding build-system maintenance as we already have to maintain CMake for ~3x platforms.

If using a more Python-native system adds additional work or produces a different kind build, I don't think that's an acceptable situation.

@Clockwork-Muse I don't think building Blender as a Python module impacts the decision on [D14954](https://archive.blender.org/developer/D14954). Unless there is something that patch fixes that we can't easily fix in our own Python finding script. --- > In #100913#1416104, @Clockwork-Muse wrote: > A while back, I proposed switching to the cmake `FindPython` module in [D14954](https://archive.blender.org/developer/D14954). Would that be appropriate to consider as part of the other changes here as well? VFX reference platform is moving to glibc 2.28, which implies an upgrade to CentOS 8/AlmaLinux 8 (where cmake 3.20 is available in the default repositories). > >> So I think any build script would not need to actually build Blender or care about its dependencies. We'd need a script to package a `bpy` folder that's already complete into a wheel, and eventually also automates uploading it to pypi. > > I *thought* I had a trivial permanent script that would do this solely with a `pyproject.toml`/`setup.cfg`, but it isn't working now. I know I have a working version that abuses `package_data` and runs from `setup.py`... but I want to revisit this. > > Why is the requirement that we package the pre-built directory, as opposed to building via scikit-build/`pip wheel`? We **already** need to do a separate build when we call `make bpy` (or `make release` with the option changes), so there isn't extra work required in that sense, and building via `pip wheel` is far cleaner. (answering for myself) while I wouldn't consider it a hard requirement - whatever solution is used should minimize any duplicate work regarding build-system maintenance as we already have to maintain CMake for ~3x platforms. If using a more Python-native system adds additional work or produces a different kind build, I don't think that's an acceptable situation.

Stephen Imhoff commented

2022-09-13 08:23:57 +02:00

If using a more Python-native system adds additional work or produces a different kind build, I don't think that's an acceptable situation.

It would re-use the existing cmake build system:

# setup.py
import os

from skbuild import setup

package_dir = "src"
package = "bpy"

setup(
    packages=[package],
    package_dir={"": package_dir},
    cmake_install_dir=package_dir,
    cmake_source_dir="/blender-git/blender",
    cmake_args=[
        "-C/blender-git/blender/build_files/cmake/config/bpy_module.cmake",
        "-DWITH_INSTALL_PORTABLE=ON",
    ]
)

(this repo branch has the entire setup required )

Call pip wheel ${WHEEL_PROJECT_DIRECTORY}, and the output is a .whl (that needs to be fixed up as needed per-platform - ie, auditwheel repair on linux - which would have to be done anyways). The wheel is then ready to install to a venv or upload to PyPi or whatever.

No changes to blender are required to enable this (and before this task showed up, I was planning on using this to package and upload blender as a wheel myself). Some of the changes in this task make the resulting packages friendlier.

> If using a more Python-native system adds additional work or produces a different kind build, I don't think that's an acceptable situation. It would re-use the existing cmake build system: ``` # setup.py import os from skbuild import setup package_dir = "src" package = "bpy" setup( packages=[package], package_dir={"": package_dir}, cmake_install_dir=package_dir, cmake_source_dir="/blender-git/blender", cmake_args=[ "-C/blender-git/blender/build_files/cmake/config/bpy_module.cmake", "-DWITH_INSTALL_PORTABLE=ON", ] ) ``` ([this repo branch has the entire setup required ](https://github.com/Clockwork-Muse/bpy/tree/scikit-build-3.4)) Call `pip wheel ${WHEEL_PROJECT_DIRECTORY}`, and the output is a `.whl` (that needs to be fixed up as needed per-platform - ie, `auditwheel repair` on linux - which would have to be done anyways). The wheel is then ready to install to a venv or upload to PyPi or whatever. No changes to blender are required to enable this (and before this task showed up, I was planning on using this to package and upload blender as a wheel myself). Some of the changes in this task make the resulting packages friendlier.

Brecht Van Lommel commented

2022-09-13 12:54:18 +02:00

In #100913#1416104, @Clockwork-Muse wrote:
Why is the requirement that we package the pre-built directory, as opposed to building via scikit-build/pip wheel?

We have a build pipeline setup for the buildbot, broken up into multiple steps, with various configuration options, logging, incremental builds, tweaks to deal with memory constraints, etc. If we do something different for the bpy module that's harder to set up and maintain.

We already need to do a separate build when we call make bpy (or make release with the option changes), so there isn't extra work required in that sense, and building via pip wheel is far cleaner.

The buildbot doesn't call make bpy, it uses cmake directly.

Building a native python wheel is simpler and easier when python initiates the build, and becomes more important as python transitions to the modern pyproject.toml build definitions, and away from setup.py. The existing python tooling does not like to wrap an externally built library, and the situation is actually going to get worse as the buildsystem modernizes (it was doable by messing around with distutils, but that's officially deprecated).

It's not obvious to me why it's hard, or why this would require deprecated functionality instead of the modern systems. If scikit-build can use setuptools to do this, then so can we?

> In #100913#1416104, @Clockwork-Muse wrote: > Why is the requirement that we package the pre-built directory, as opposed to building via scikit-build/`pip wheel`? We have a build pipeline setup for the buildbot, broken up into multiple steps, with various configuration options, logging, incremental builds, tweaks to deal with memory constraints, etc. If we do something different for the bpy module that's harder to set up and maintain. > We **already** need to do a separate build when we call `make bpy` (or `make release` with the option changes), so there isn't extra work required in that sense, and building via `pip wheel` is far cleaner. The buildbot doesn't call `make bpy`, it uses cmake directly. > Building a native python wheel is simpler and easier when python initiates the build, and becomes more important as python transitions to the modern `pyproject.toml` build definitions, and away from `setup.py`. The existing python tooling does *not* like to wrap an externally built library, and the situation is actually going to get worse as the buildsystem modernizes (it was doable by messing around with `distutils`, but that's officially deprecated). It's not obvious to me why it's hard, or why this would require deprecated functionality instead of the modern systems. If `scikit-build` can use `setuptools` to do this, then so can we?

Stephen Imhoff commented

2022-09-13 19:24:02 +02:00

If we do something different for the bpy module that's harder to set up and maintain.
The buildbot doesn't call make bpy, it uses cmake directly.

Right, but my point was that at least WITH_MEM_JEMALLOC is explicitly turned off for the bpy build, which is on for (most of?) the rest of the builds. It's not clear to me how much of the existing build output the bpy build can re-use.
It is possible, although I haven't tested it, that because scikit-build directly uses cmake as well it may be able to integrate with external incremental builds.

If scikit-build can use setuptools to do this, then so can we?

The problem is that setuptools itself doesn't expose a way to just wrap up a pre-compiled archive/object file (not without either a lot of customization, or a hacky/unintended/unsupported approach). The way the tools are intended to work - and are migrating more heavily towards enforcing - is that python controls the build process from source.

There are a couple of additional avenues I can explore here;

The hacky way is relatively short (only like a couple of lines), but gets a working wheel somewhat as a side effect. I can't guarantee it would work long term.
A better customized command for wrapping the directory is maybe 20-30 lines? This is likely to work longer term.

> If we do something different for the bpy module that's harder to set up and maintain. > The buildbot doesn't call `make bpy`, it uses cmake directly. Right, but my point was that at least `WITH_MEM_JEMALLOC` is explicitly turned off for the bpy build, which is on for (most of?) the rest of the builds. It's not clear to me how much of the existing build output the bpy build can re-use. It is possible, although I haven't tested it, that because scikit-build directly uses cmake as well it may be able to integrate with external incremental builds. > If `scikit-build` can use `setuptools` to do this, then so can we? The problem is that `setuptools` itself doesn't expose a way to just wrap up a pre-compiled archive/object file (not without either a lot of customization, or a hacky/unintended/unsupported approach). The way the tools are intended to work - and are migrating more heavily towards enforcing - is that python controls the build process from source. There are a couple of additional avenues I can explore here; - The hacky way is relatively short (only like a couple of lines), but gets a working wheel somewhat as a side effect. I can't guarantee it would work long term. - A better customized command for wrapping the directory is maybe 20-30 lines? This is likely to work longer term.

Brecht Van Lommel commented

2022-09-13 20:11:45 +02:00

In #100913#1416561, @Clockwork-Muse wrote:
Right, but my point was that at least WITH_MEM_JEMALLOC is explicitly turned off for the bpy build, which is on for (most of?) the rest of the builds. It's not clear to me how much of the existing build output the bpy build can re-use.
It is possible, although I haven't tested it, that because scikit-build directly uses cmake as well it may be able to integrate with external incremental builds.

jemalloc is mostly a link option, but there is some stuff that indeed needs to be rebuilt. But for example GPU binaries or libmv would not need to be rebuilt.

The main concern is maintenance cost. I'm not worried it's impossible to setup scikit-build to do incremental builds for example, but rather I don't want to maintain two different ways of doing incremental builds.

The problem is that setuptools itself doesn't expose a way to just wrap up a pre-compiled archive/object file (not without either a lot of customization, or a hacky/unintended/unsupported approach). The way the tools are intended to work - and are migrating more heavily towards enforcing - is that python controls the build process from source.

There are a couple of additional avenues I can explore here;

The hacky way is relatively short (only like a couple of lines), but gets a working wheel somewhat as a side effect. I can't guarantee it would work long term.

A better customized command for wrapping the directory is maybe 20-30 lines? This is likely to work longer term.

I added the buildbot side support, and created a very basic packaging script to validate it works: D15957: Python: script for packing bpy module as wheel

What would help now is making this complete, generating correct packages for all platforms, ensuring tests pass, etc.

> In #100913#1416561, @Clockwork-Muse wrote: > Right, but my point was that at least `WITH_MEM_JEMALLOC` is explicitly turned off for the bpy build, which is on for (most of?) the rest of the builds. It's not clear to me how much of the existing build output the bpy build can re-use. > It is possible, although I haven't tested it, that because scikit-build directly uses cmake as well it may be able to integrate with external incremental builds. jemalloc is mostly a link option, but there is some stuff that indeed needs to be rebuilt. But for example GPU binaries or libmv would not need to be rebuilt. The main concern is maintenance cost. I'm not worried it's impossible to setup scikit-build to do incremental builds for example, but rather I don't want to maintain two different ways of doing incremental builds. > The problem is that `setuptools` itself doesn't expose a way to just wrap up a pre-compiled archive/object file (not without either a lot of customization, or a hacky/unintended/unsupported approach). The way the tools are intended to work - and are migrating more heavily towards enforcing - is that python controls the build process from source. > > There are a couple of additional avenues I can explore here; > - The hacky way is relatively short (only like a couple of lines), but gets a working wheel somewhat as a side effect. I can't guarantee it would work long term. > - A better customized command for wrapping the directory is maybe 20-30 lines? This is likely to work longer term. I added the buildbot side support, and created a very basic packaging script to validate it works: [D15957: Python: script for packing bpy module as wheel](https://archive.blender.org/developer/D15957) What would help now is making this complete, generating correct packages for all platforms, ensuring tests pass, etc.

Stephen Imhoff commented

2022-09-14 00:13:21 +02:00

The use of package_data in D15957 is the "hacky" way I mentioned. The problem is that the wheel it generates doesn't reference a minor python version (eg, 3 instead of 3.10 as it should), because it doesn't know that the files that get pulled in are native modules. To an extent it thinks it's doing a python-only wheel. This may cause it to break under odd conditions (although in my current use of such a package, I haven't run into anything I directly attribute to that).

The "proper" way to do this is probably to subclass one of the build/sub-build commands, and essentially just claim to have built the existing files. We shouldn't need any changes to blender itself, other than the changes already present in this task (principally 81558783e4 - if we want to build the wheel for prior versions of blender we'd need to backport that to keep the module name).

Building a modern python wheel is normally done with python -m build --wheel <package directory> or pip wheel <package directory>, rather than calling setup.py/bdist_wheel directly. My intention is to contribute a wrapper package set up as if it were a modern native-lib python package, with a custom build command that would claim to have built the existing artifacts. This should work correctly for all platforms, and the only platform difference would be the use of auditwheel/delocate or similar after the wheel is built to correct the native links.

The use of `package_data` in [D15957](https://archive.blender.org/developer/D15957) is the "hacky" way I mentioned. The problem is that the wheel it generates doesn't reference a minor python version (eg, 3 instead of 3.10 as it should), because it doesn't know that the files that get pulled in are native modules. To an extent it thinks it's doing a python-only wheel. This *may* cause it to break under odd conditions (although in my current use of such a package, I haven't run into anything I directly attribute to that). The "proper" way to do this is probably to subclass one of the build/sub-build commands, and essentially just claim to have built the existing files. We shouldn't need any changes to blender itself, other than the changes already present in this task (principally 81558783e4 - if we want to build the wheel for prior versions of blender we'd need to backport that to keep the module name). Building a modern python wheel is normally done with `python -m build --wheel <package directory>` or `pip wheel <package directory>`, rather than calling `setup.py`/`bdist_wheel` directly. My intention is to contribute a wrapper package set up as if it were a modern native-lib python package, with a custom build command that would claim to have built the existing artifacts. This should work correctly for all platforms, and the only platform difference would be the use of `auditwheel`/`delocate` or similar after the wheel is built to correct the native links.

Brecht Van Lommel commented

2022-09-14 13:24:30 +02:00

My intention is to contribute a wrapper package set up as if it were a modern native-lib python package, with a custom build command that would claim to have built the existing artifacts.

How would developers or the buildbot use this, would they call e.g. pip wheel ../build_linux_bpy/bin?

I guess for most developers a target like make bpy wheel would be most convenient.

the only platform difference would be the use of auditwheel/delocate or similar after the wheel is built to correct the native links.

Is that necessary? These seem to be copying system dynamic libraries into the package, but Blender executables should already be self contained enough.

> My intention is to contribute a wrapper package set up as if it were a modern native-lib python package, with a custom build command that would claim to have built the existing artifacts. How would developers or the buildbot use this, would they call e.g. `pip wheel ../build_linux_bpy/bin`? I guess for most developers a target like `make bpy wheel` would be most convenient. > the only platform difference would be the use of auditwheel/delocate or similar after the wheel is built to correct the native links. Is that necessary? These seem to be copying system dynamic libraries into the package, but Blender executables should already be self contained enough.

Stephen Imhoff commented

2022-09-14 16:43:14 +02:00

How would developers or the buildbot use this, would they call e.g. pip wheel ../build_linux_bpy/bin?

That or python -m build <whatever directory>, yes.

Is that necessary? These seem to be copying system dynamic libraries into the package, but Blender executables should already be self contained enough.

At minimum, it adjusts wheel name/metadata for linux (not as sure about other platforms), from linux1 to manylinux<something> (assuming we're building on centos7, manylinux2014_<platform>). Even if the binaries are already usable, you still need that to occur so that it's installable on multiple distros from PyPi.
When messing with another package, I believe I'd tried to manually adjust the name itself, but that rendered it unusable/uninstallable.

About scikit-build -
I have experimentally verified that it does re-use build cache, however the process does disturb it, and still re-links __init__.so , and in at least the initial tests performed doesn't properly install the output/build the wheel (because it seems to want to re-use the existing install prefix).

> How would developers or the buildbot use this, would they call e.g. `pip wheel ../build_linux_bpy/bin`? That or `python -m build <whatever directory>`, yes. > Is that necessary? These seem to be copying system dynamic libraries into the package, but Blender executables should already be self contained enough. At minimum, it adjusts wheel name/metadata for linux (not as sure about other platforms), from `linux1` to `manylinux<something>` (assuming we're building on centos7, `manylinux2014_<platform>`). Even if the binaries are already usable, you still need that to occur so that it's installable on multiple distros from PyPi. When messing with another package, I believe I'd tried to manually adjust the name itself, but that rendered it unusable/uninstallable. About scikit-build - I have experimentally verified that it **does** re-use build cache, however the process does disturb it, and still re-links `__init__.so` , and in at least the initial tests performed doesn't properly install the output/build the wheel (because it seems to want to re-use the existing install prefix).

Brecht Van Lommel commented

2022-09-14 20:58:47 +02:00

Ok, my preference is to not rely on additional modules like scikit-build, auditwheel, delocate unless they do something we can't do ourselves with a few lines of code. If they do something more complicated then so be it, but it doesn't seem clear yet.

Ok, my preference is to not rely on additional modules like `scikit-build`, `auditwheel`, `delocate` unless they do something we can't do ourselves with a few lines of code. If they do something more complicated then so be it, but it doesn't seem clear yet.

Tyler Alden Gubala commented

2022-09-14 23:16:45 +02:00

@Clockwork-Muse Started the transfer process:

https://github.com/pypa/pypi-support/issues/2231

@Clockwork-Muse Started the transfer process: https://github.com/pypa/pypi-support/issues/2231

Stephen Imhoff commented

2022-09-14 23:22:46 +02:00

@TylerGubala - I'm just an interested party, I'm not an admin or anything, the person to ping is probably @brecht

Brecht Van Lommel commented

2022-09-15 19:26:14 +02:00

It seems @ideasman42 is the one in contact about the transfer, so will let him handle it unless my help is needed.

Brecht Van Lommel commented

2022-09-15 21:31:13 +02:00

bpy wheels can be downloaded here for testing now:
https://builder.blender.org/download/experimental/

Developers with a buildbot account can kick off a branch build (set to master) to update this. It's not part of the daily builds yet.

bpy wheels can be downloaded here for testing now: https://builder.blender.org/download/experimental/ Developers with a buildbot account can kick off a branch build (set to `master`) to update this. It's not part of the daily builds yet.

Stephen Imhoff commented

2022-09-16 01:22:12 +02:00

Question - will the module changes be included in 3.3 bugfixes, or starting in 3.4?

Brecht Van Lommel commented

2022-09-16 02:44:19 +02:00

All the changes are in 3.4, I'm not aware of any plan to backport it.

Zach Eastin commented

2022-09-16 04:55:27 +02:00

Added subscriber: @Zeastin

Campbell Barton commented

2022-09-23 06:55:13 +02:00

As far as I'm aware the main TODO's in this task are done.

Some loose ends though:

Tyler created this ticket to transfer ownership of the PIP bpy package to the Blender-Foundation.
@brecht if we have the ability to upload wheel's would be upload our builds as wheels (generated from the build-bot) ?
Feedback on Python API documentation for Blender as a Python Module would be appreciated.

As far as I'm aware the main TODO's in this task are done. Some loose ends though: - Tyler created [this ticket ](https://github.com/pypa/pypi-support/issues/2231) to transfer ownership of the PIP `bpy` package to the Blender-Foundation. - @brecht if we have the ability to upload wheel's would be upload our builds as wheels (generated from the build-bot) ? - Feedback on [Python API documentation for Blender as a Python Module ](https://docs.blender.org/api/3.4/info_advanced_blender_as_bpy.html) would be appreciated.

Robert Guetzkow commented

2022-09-26 21:14:58 +02:00

Added subscriber: @rjg

Robert Guetzkow commented

2022-09-26 21:14:58 +02:00

Just so that it is not forgotten, the wiki page will need to be updated as well: https://wiki.blender.org/wiki/Building_Blender/Other/BlenderAsPyModule

Campbell Barton commented

2022-09-26 22:49:10 +02:00

@rjg noted, the page has been updated to reflect recent changes (API docs, utility to create *.whl) but the text regarding official support remains unchanged for now.

@rjg noted, the page has been updated to reflect recent changes (API docs, utility to create `*.whl`) but the text regarding official support remains unchanged for now.

Raimund Klink commented

2022-10-11 18:38:48 +02:00

@ideasman42 Please react to https://github.com/pypa/pypi-support/issues/2231
They want a defined owner.
You might need to create an account for the BF https://pypi.org/account/register/

@ideasman42 Please react to https://github.com/pypa/pypi-support/issues/2231 They want a defined owner. You might need to create an account for the BF https://pypi.org/account/register/

Campbell Barton commented

2022-10-13 03:08:48 +02:00

In #100913#1430847, @Raimund58 wrote:
@ideasman42 Please react to https://github.com/pypa/pypi-support/issues/2231
They want a defined owner.
You might need to create an account for the BF https://pypi.org/account/register/

Thanks for letting us know, replied with details for the account to use.

> In #100913#1430847, @Raimund58 wrote: > @ideasman42 Please react to https://github.com/pypa/pypi-support/issues/2231 > They want a defined owner. > You might need to create an account for the BF https://pypi.org/account/register/ Thanks for letting us know, replied with details for the account to use.

Lin Hsu commented

2022-10-14 09:47:53 +02:00

Added subscriber: @Lin-Hsu

Rin Arakaki commented

2022-10-16 09:04:08 +02:00

Added subscriber: @synthetic

Raimund Klink commented

2022-10-28 15:25:33 +02:00

@ideasman42 Hi, since the Blender Foundation is now (co)owner of the pip bpy module, what are the next steps?
That is not clear from the task as I can see it.
Will bpy be the build from the latest release and bpy-master a nightly build?

@ideasman42 Hi, since the Blender Foundation is now (co)owner of the pip `bpy` module, what are the next steps? That is not clear from the task as I can see it. Will `bpy` be the build from the latest release and `bpy-master` a nightly build?

Brecht Van Lommel commented

2022-10-28 16:00:29 +02:00

I think we'd wait until the Blender 3.4 release is out and then manually trigger a bpy build on the buildbot and upload it. Later that can get automated as part of the release process.

It would be good to try it out on the pypi test instance beforehand.

I don't expect us to publish nightly builds to pypi.

I think we'd wait until the Blender 3.4 release is out and then manually trigger a bpy build on the buildbot and upload it. Later that can get automated as part of the release process. It would be good to try it out on the pypi test instance beforehand. I don't expect us to publish nightly builds to pypi.

Raimund Klink commented

2022-10-28 16:48:12 +02:00

Thank you, Becht, for answering. Looking forward to get official bpy and pip support :)

Stephen Imhoff commented

2022-10-28 19:44:21 +02:00

I don't expect us to publish nightly builds to pypi.

Perhaps not nightlies (at least not until PyPi better supports them), but alpha/beta/rc might be reasonable? That would serve for testing the PyPi process, and getting feedback from people taking dependencies. Note that, due to the way pip works, you have to either explicitly list a pre-release version number, or enable pulling pre-release packages in general, which means that normally such packages are effectively hidden.

> I don't expect us to publish nightly builds to pypi. Perhaps not nightlies (at least not until PyPi better supports them), but alpha/beta/rc might be reasonable? That would serve for testing the PyPi process, and getting feedback from people taking dependencies. Note that, due to the way pip works, you have to either explicitly list a pre-release version number, or enable pulling pre-release packages in general, which means that normally such packages are effectively hidden.

Stephen Imhoff commented

2022-10-31 02:11:54 +01:00

Side note: I have just been made aware of https://test.pypi.org/. This is intended for use in testing CI scripts, not for distribution of pre-release packages, so should help when those scripts get written.

Saman commented

2022-10-31 16:06:50 +01:00

Added subscriber: @samrun

Saman commented

2022-10-31 16:06:50 +01:00

Hi, thank you for development around building Blender bpy as a python module. I have two suggestions for improvement and not sure how easy or possible it is with the CMake build.

I was able to follow the docs and build bpy and import it in a python script but the build file (iso) is very large (~400mb) and may not be a feasible solution for publishing anything with it. It be great if we have the option to opt out of some the modules so it reduces this size.
bpy as a python module is relatively very slow and not able to use it in anything like an engine. Like I tried to automate a simple cube creation and it takes 300ms. I suspect this is because of the disk writes for .blend file or anything internally going on.

Thank you!

Hi, thank you for development around building Blender bpy as a python module. I have two suggestions for improvement and not sure how easy or possible it is with the CMake build. - I was able to follow the docs and build bpy and import it in a python script but the build file (iso) is very large (~400mb) and may not be a feasible solution for publishing anything with it. It be great if we have the option to opt out of some the modules so it reduces this size. - bpy as a python module is relatively very slow and not able to use it in anything like an engine. Like I tried to automate a simple cube creation and it takes 300ms. I suspect this is because of the disk writes for .blend file or anything internally going on. Thank you!

Ray molenkamp commented

2022-10-31 16:33:17 +01:00

300 ms is likely just the startup cost of blender, if you run the automation twice from a single python script, is it faster the second time around?

Brecht Van Lommel commented

2022-10-31 16:55:49 +01:00

It would be nice if this could be used for publishing software, but I think that's not a goal here. The GPL already makes that impossible for many cases. But also Blender is just not designed as separate components you can easily pick and choose, unless you do a custom build and disable options.

The main use cases I think are things like scientific research, machine learning, pipeline automation, web services, etc.

It would be nice if this could be used for publishing software, but I think that's not a goal here. The GPL already makes that impossible for many cases. But also Blender is just not designed as separate components you can easily pick and choose, unless you do a custom build and disable options. The main use cases I think are things like scientific research, machine learning, pipeline automation, web services, etc.

Brecht Van Lommel commented

2022-11-01 14:30:25 +01:00

I requested to increase the package size limit since we exceed the current one:
https://github.com/pypa/pypi-support/issues/2353

I requested to increase the package size limit since we exceed the current one: https://github.com/pypa/pypi-support/issues/2353

Brecht Van Lommel commented

2022-11-28 19:55:28 +01:00

Manual builds now enabled on release and daily tracks, downloadable from here: https://builder.blender.org/download/bpy/
Beta on pypi: https://pypi.org/project/bpy/3.4.0b2/ (will be removed on actual 3.4.0 release to save on space)

* Manual builds now enabled on release and daily tracks, downloadable from here: https://builder.blender.org/download/bpy/ * Beta on pypi: https://pypi.org/project/bpy/3.4.0b2/ (will be removed on actual 3.4.0 release to save on space)

Brecht Van Lommel commented

2022-11-28 21:00:10 +01:00

I added a source code link in the description as well now, and removed @TylerGubala from the pypi project maintainers and added a credit in the project description instead. These will show up on the official release, don't think I can update the project description without making another release.

artem commented

2022-11-29 09:51:08 +01:00

Added subscriber: @lobziq

artem commented

2022-11-29 09:51:08 +01:00

Apple silicon m1, python 3.8. Running command

pip install bpy==3.4.0b2

results in error

ERROR: Could not find a version that satisfies the requirement bpy==3.4.0b2 (from versions: 0.0.0a0)
ERROR: No matching distribution found for bpy==3.4.0b2

Apple silicon m1, python 3.8. Running command ``` pip install bpy==3.4.0b2 ``` results in error ``` ERROR: Could not find a version that satisfies the requirement bpy==3.4.0b2 (from versions: 0.0.0a0) ERROR: No matching distribution found for bpy==3.4.0b2 ```

artem commented

2022-11-29 09:54:41 +01:00

[Blender as a Python Module] link from https://pypi.org/project/bpy/3.4.0b2/ redirects to 404 docs url
https://docs.blender.org/api/current/info_advanced_blender_as_bpy.html

[Blender as a Python Module] link from https://pypi.org/project/bpy/3.4.0b2/ redirects to 404 docs url https://docs.blender.org/api/current/info_advanced_blender_as_bpy.html

Raimund Klink commented

2022-11-29 10:04:43 +01:00

@lobziq You use the wrong python version. Each Blender release supports one Python version, and the package is only compatible with that version. You need Python 3.10

But let's keep this task free of support requests. Come to blender.chat for chatting.

@lobziq You use the wrong python version. Each Blender release supports one Python version, and the package is only compatible with that version. You need Python 3.10 But let's keep this task free of support requests. Come to `blender.chat` for chatting.

Raimund Klink commented

2022-11-29 10:06:54 +01:00

In #100913#1452882, @lobziq wrote:
[Blender as a Python Module] link from https://pypi.org/project/bpy/3.4.0b2/ redirects to 404 docs url
https://docs.blender.org/api/current/info_advanced_blender_as_bpy.html

The link will start working once 3.4 is out.
It's docs.blender.org/api/master/info_advanced_blender_as_bpy.html

(thanks to brecht)

> In #100913#1452882, @lobziq wrote: > [Blender as a Python Module] link from https://pypi.org/project/bpy/3.4.0b2/ redirects to 404 docs url > https://docs.blender.org/api/current/info_advanced_blender_as_bpy.html The link will start working once 3.4 is out. It's docs.blender.org/api/master/info_advanced_blender_as_bpy.html (thanks to brecht)

Charlie Hewitt commented

2023-01-11 11:25:11 +01:00

Added subscriber: @chewitt

Charlie Hewitt commented

2023-01-11 11:25:11 +01:00

Hey - not sure if this warrants a separate issue but here seems relevant...
Firstly this is awesome! Thanks so much for adding this functionality, it is saving us a huge amount of effort

I wanted to ask whether it is documented anywhere what build options are being used for the wheel on pypi, and if they match the release version of blender.
Currently it seems like alembic support is not included in bpy but is in blender - is it possible to use the same options as the release version of blender for consistency, or at a minimum add support for alembic to the bpy build?

EDIT: Now see you have pre-empted this already: 9189260880 Please disregard the above! I was getting a segfault for something unrelated and assumed it was due to alembic support not being included...

Hey - not sure if this warrants a separate issue but here seems relevant... Firstly this is awesome! Thanks so much for adding this functionality, it is saving us a huge amount of effort I wanted to ask whether it is documented anywhere what build options are being used for the wheel on pypi, and if they match the release version of blender. Currently it seems like alembic support is not included in bpy but is in blender - is it possible to use the same options as the release version of blender for consistency, or at a minimum add support for alembic to the bpy build? EDIT: Now see you have pre-empted this already: 9189260880 Please disregard the above! I was getting a segfault for something unrelated and assumed it was due to alembic support not being included...

Philipp Oeser removed the

Download

What's New

Blender Studio

Manual

Developers Blog

Documentation

Benchmark

Blender Conference

Development Fund

One-time Donations

Improve support for building Blender as a Python Module (WITH_PYTHON_MODULE) #100913

Proposal

Motivation

TODO

Possible Changes

Open Topics

Out of Scope

Progress

Other Remarks