Upcoming Deprecation: Legacy Script Metadata in IronPython Scripts

Collective
1

Hi everyone :waving_hand:

We’re discussing a change to how pyRevit handles legacy metadata embedded directly inside IronPython script files.

As part of the ongoing work around the new launcher and startup performance improvements, we’re evaluating removing support for inline legacy metadata parsing in scripts and moving fully toward “bundle.yaml”-based metadata.

Why?

The current metadata parsing process adds overhead during extension loading, especially with the new launcher/rocket-mode work. Initial investigations suggest that skipping this legacy parsing could noticeably improve startup/loading times.

That said, we know many extensions and internal tools still rely on this older format, so we want to make the transition as smooth as possible.

Current Direction

The current proposal is:

  • Keep support for now
  • Add a deprecation notice in an upcoming release
  • Provide a helper migration script to automatically move legacy metadata into “bundle.yaml”
  • Update documentation/examples accordingly
  • Remove support in a future major release (likely pyRevit 7.x)

There’s also discussion around making metadata parsing optional/skippable for rocket mode as an intermediate step, instead of immediately removing support.

What This Means for Extension Authors

If your scripts still use inline metadata like:

title = “My Tool”
author = “Me”
doc = “Tool description”

you should start planning to migrate that information into “bundle.yaml” files.

We’d Love Feedback

Before moving forward, we’d really appreciate community input:

  • Are you still relying heavily on inline metadata?
  • Would an automated migration helper cover most cases for you?
  • Would a “skip metadata parsing” performance flag be preferable before full removal?
  • Have you measured any startup impact in large extensions?

The goal here is faster loading times without unnecessarily breaking existing workflows.

Thanks everyone :raising_hands:

4 Likes
3

This seems like a reasonable plan. My scripts do use inline metadata but I don’t mind the idea of shifting them to bundle files. Perhaps the automated migration could convert the inlines to comments so the context is still there when you open a file.

A tangential thought. Could the bundle file be used to force the Shift+Click dot indicator for scripts that include that behavior within a parent script rather than a config file. Something like shift_click = True in the bundle file and if EXEC_PARAMS.config_mode: in the main script.

1 Like
4

You can just append the indicator to the title yourself - no need to hassle with a new keyword imo

title: "Transfer\nElements \u25cF"
2 Likes
5

Here’s a data point for you: I don’t use any inline metadata, so I’m all for any performance improvements by removing support for it.

2 Likes
6

I’ve been using the bundle.yaml for all of my tools. So agree that any performance increase is welcome. It seems to me, that it would be fair to give some time for everyone to adjust to this change by notifying of this in pyRevit itself. And agree to do the breaking chance with a major release.

1 Like
7

Here is my input. I hope it helps

  • Are you still relying heavily on inline metadata? Not anymore. I started using the bundle.yaml method about a year ago. Prior to that, I did use inline metadata a lot.

  • Would an automated migration helper cover most cases for you? Yes, or a tool that would tell us which tools we need to update rather than us having to open each file to track down inline metadata.

  • Would a “skip metadata parsing” performance flag be preferable before full removal? N/A

  • Have you measured any startup impact in large extensions? N/A. I have never really paid attention to this much. However, I am now testing auto-updates to the tools via the startup.py to pull from github and did notice a lag but not a major impact.

1 Like
8

Im not using any inline metadata.

ok for slowly removing this.

1 Like