Guidance on Migrating from pyRevit 4.5 to 4.8

Hi everyone,

We’re currently in the process of updating our old pyRevit setup to be integrated with the latest pyRevit version. Our original setup was based on a fork/clone of pyRevit 4.5.X, with most of the custom code integrated directly into site-packages and pyrevitlib. We’re making efforts to relocate our custom code to the lib folder in the new cusyom extension as part of this migration.

As we navigate through this transition, we have a couple of questions and would really appreciate any insights or advice from the community:

  1. Core Changes from 4.5 to 4.8:
    What are the major differences between pyRevit versions 4.5 and 4.8? Is there an efficient way to compare an original 4.5 repository to our customized repository to identify potential integration issues or necessary updates?
    We done the move to yaml files, so that part is covered. The cleanengine we fixed, but we are unsore about the fulmframeengine, does that still need to be configured?

  2. Tab Management for Multiple Disciplines:
    In our previous setup, we handled each tab as a separate custom extension, utilizing the Extension mechanism to activate/deactivate tabs as needed by different disciplines. With the updates in pyRevit, is this approach still considered best practice for managing multiple tabs? Or is it more advisable to consolidate these tabs within a single extension and control visibility through pushbuttons etc.?

  3. Deployment Strategies:
    For deploying the updated pyRevit, should we clone the pyRevit core/base to a DevOps repository and reference that as “ourpyrevitcore” during CLI installations? Alternatively, is it preferable to store the core/base on a server or network drive for access? We’re looking for insights on the most efficient and effective deployment practices.

We’ve managed to get our new “2.0-version” mostly up and running but are seeking some final pieces of advice to iron out the remaining kinks.

Thanks in advance for your help and guidance!

Best regards,
Jonn Ø

A small update on this.

Point 1 and 3 is mostly solved, so we dont need spesific tips on those any more.

Regarding tab management, we have mapped some pros and cons for two alternatives:

Alt 1 - Multiple extensions:
It looks like pyRevit should handle multiple custom extensions in a good way, installing them using extensions.json and the built in Extensions-installer, but our problem is that all our tabs need to share the same /lib-folder, and we have not found an easy way to have one /lib-folder for multiple extensions. Any suggestions?

Alt 2 - Multiple tabs:
We cannot find a native way to hide/unhide tabs easily, but this looks like the better option for us. Pros is that all our code could stay in the same repo, and the /lib-folder can be shared easily for all tabs etc. We might look into using the same logic as the MinifyUI function to hide/unhide the tabs, storing the user selections in a custom config file. Does anyone think that is an option?

You can make a lib extension. As simple as that.

Yep, way to go. How do you determine the discipline of the ppl programmatically? Checking against a list?

You could have button based on the minify UI one.
One for each discipline and make it hide a predefined tab.

Or just have separate deployment depending on the discipline. Therefore not having to worry about hiding stuffs in the first place.

I’d make a diagram of extensions, libs, and deployment process to clear things out

1 Like

Oh, nice, we’ll have to look into that!

We don’t, in the previous version the users activate the discipline-extension they want manually.

I was able to make a “toggle” button to hide/unhide each tab (the script just iterates through the tabs in Revit and hides/unhides the one defined in each toggle button and then swaps the icon from on to off and vice versa). But all tabs are loaded on startup, so it does not work for us.

Thank you for your reply, we’ll look into the lib extension and/or check if we can make a “minifyUI” for only our tabs that are loaded on startup. (I know that loading setup on startup is possibly hard to do, based on other discussions I have read here.)