Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Xblock version 5.0.0 broke plugin #777

Closed
BrandonHBodine opened this issue Aug 7, 2024 · 4 comments · Fixed by #778
Closed

Xblock version 5.0.0 broke plugin #777

BrandonHBodine opened this issue Aug 7, 2024 · 4 comments · Fixed by #778
Assignees

Comments

@BrandonHBodine
Copy link
Member

We have a plugin that is replacing the default XBlock with our own implementation that was recently broken with what we believe was the removal of pkg_resources support here #716.

We followed this post as our way of implementation https://discuss.openedx.org/t/override-default-edx-platform-xblock-mappings-without-forking/12441

Suspected root of the issue in our plugin:

    def ready(self):
        """
        Django startup code: swap edx-platform mapping for blocks with our translated versions.

        See https://discuss.openedx.org/t/override-default-edx-platform-xblock-mappings-without-forking/12441
        """

        # List of translated block types, for dismbiguating entry points
        translated_blocks = ["html", "problem", "video"]

        for block_type in translated_blocks:
            block_entry_points = list(
                pkg_resources.iter_entry_points("xblock.v1", block_type)
            )

            # If we have multiple entry points, ours gets precedence over the Open-edX copy
            if len(block_entry_points) > 1:
                dist = pkg_resources.get_distribution("Open-edX")
                del dist.get_entry_map("xblock.v1")[block_type]
@kdmccormick
Copy link
Member

Thanks for the report. The root issue you've found looks correct to me. We've switched XBlock over from pkg_resources to importlib.metadata, and it seems that hack which worked before on pkg_resources does not apply over in importlib.metadata land.

On one hand, pkg_resources is not part of the public XBlock API, so I do not consider this to be a bug in XBlock. On the other hand, it seems valuable for operators to be able to customize XBlocks without forking edx-platform, so I do want to make sure there's a "supported workaround" for that.

I will spend some time this week thinking if there is a supported API we could add to XBlock for customizing blocks. In the meantime, @BrandonHBodine , let me know if you find a new workaround that works with XBlock==5.0.0.

@kdmccormick
Copy link
Member

@nsprenkle
Copy link
Contributor

I've posted an idea in https://discuss.openedx.org/t/override-default-edx-platform-xblock-mappings-without-forking/12441/4

Following up with this, I like the idea of having an XBlock-supported way to override a block as suggested by @kdmccormick. Happy to help design / review as we are under time pressure to get a change out.

@pomegranited
Copy link
Contributor

pomegranited commented Aug 22, 2024

Excellent fix for this issue @nsprenkle and @kdmccormick, thank you!

Do you know if anyone is working on removing the XBlock constraint from edx-platform? I don't want to upgrade to XBlock==5.1.0 in completion until we're using it in the platform.

Sorry for the noise! Found your openedx/edx-platform#35325.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants