The Future of pyRevit Amidst .NET Framework Changes

Hi everyone,

Since recent updates, Dynamo has transitioned to the .NET 6.0 framework, leading me to anticipate a similar update for Revit itself.
from the revit roadmap: .NET 6 or higher

Recently, I had the pleasure of watching the first pyRevit meetup pyRevit meetup #1.
The discussion was both refreshing and open, sparking my interest in future conversations.
Among the topics discussed was the transition to the .NET framework, which left me curious about the pyRevit team’s perspective on this change.

Here are a few questions I’m pondering:

  • Is there a timeline for when Revit will complete its upgrade to the newer .NET version?
  • What is the expected duration for this upgrade process?
  • Will this necessitate modifications to existing scripts to ensure their functionality?
  • Is it possible we’ll see a core release of pyRevit? One where pyRevit is operational and can load extensions, even if not all scripts (from pyrevit itself) are immediately functional.
  • What other implications might this update have on pyRevit?

Understanding these aspects is important for us to potentially prepare for the upcoming changes. In our office, we have developed several foundational automations using Python for pyRevit. As architects, designers, and engineers who have a passion for coding, Python has been an ideal language for us. And so we hope to avoid transitioning to a more complicated C# in the future.

I also want to take a moment to express my gratitude to the pyRevit team for their relentless dedication over the years. The tools and support provided by pyRevit have revolutionized coding for Revit, making automation and customization accessible to many.
Your hard work has truly transformed the way we approach design and engineering tasks. Thank you for everything you have done and for what’s to come in the future. Without pyRevit, the possibilities for coding within Revit wouldn’t be as vast as they are today.

I appreciate any insights you might have and look forward to brainstorming solutions and ideas regarding this topic.

Thank you all in advance for your contributions.

6 Likes

C# is not complicated than python. it is a myth!

At my job, I allocated 2 years to update pyRevit and my add-ons. :wink::smirk:

Good points @AlexanderVDB

We are having a second pyRevit meetup, and Ehsan should be there as well. This will be the best place to discuss your points

pyRevit meetup #2 - Monday 16.30 CET

Forgive me for the off-topic, but I couldn’t resist :sweat_smile:

I agree, but the problem is that the developing process is more cumbersome!

  • boilerplate code for command definition and ribbon button creation
  • need to restart revit at each code edit
  • some more boilerplate to package the add in with the manifest, sign the binaries, create the installer and sign it

For someone starting the coding journey these are major turndown points… that’s why projects like Dynamo and pyRevit are so popular in AEC…

2 Likes
  • boilerplate code for command definition and ribbon button creation

I use pyRevit :smiley: with C# assemblies

  • need to restart revit at each code edit

I use pyRevit :smiley: and AddinManager for testing

  • some more boilerplate to package the add in with the manifest, sign the binaries, create the installer and sign it

I use pyRevit :smiley: but create one .addin file and copy with build I not hard.

my list :slight_smile:

  • I had to create an even more complex installer with pyRevit than I would have created with regular C# code. My installer monitors the installed pyRevit, and reinstalls it if it is already outdated, I also have to create different features so that the user can choose and install the correct version of my platform, which is pulled from github
  • python doesn’t have debugger, write print is so terrible
  • python code cannot be compiled, so you will learn about errors after starting, and not immediately
  • on python write GUI a separate type of suffering
  • on python you need to write in two styles simultaneously PEP8 and PascalCase (C#)
  • code completion (intellisense)
  • etc
1 Like

Oh sorry, now I get your point! :wink:

Indeed a strongly typed, compiled language has its advantages. That’s why, in my python 3.10+ code outside pyrevit, I use typing annotations and linters to mitigate runtime errors. Too bad this is not possible in IronPython…

Well, pyrevit supports debugging with pdb in its output window: you can import pdb; pdb.set_trace() to activate it.
But it has some problems, I opened an issue a while ago but never got the time to investigate it further.

I always felt that the current directory structure, while convenient for the newcomers to build their own ribbon, it’s a nightmare for IDEs and for the loading logic in pyRevit.
I still have to reason about a good solution, and I’m focusing on python scripts, but I suppose that an extension could be transformed into a regular python package that has a single yaml manifest with the extension info and ribbon layout; each button/widget would state the name of the module to call a-la setuptools (package.subpackage.module:function).

I’m getting more and more off-topic, but it that’s somenthing we can discuss for the next major release :wink:

1 Like