Import libraries inside pyRevit environment

Revit API
1

Can anyone please explain what is the right way to start working in pyRevit environment. I mean what “must have” libraries I need to import to start working?

I tried to study various scripts and everyone uses different methods.

  1. Some people use clr. Do I need to import this when working in pyrevit?
    import clr
    clr.AddReference(“RevitAPI”)

  2. Some people do this which does not make sense.
    from Autodesk.Revit.DB import Workset, Transaction
    (this line makes sense as a person tries to create worksets and record transaction so it can be undone).
    from Autodesk.Revit.DB import *
    (then they do this which does not make sense. They have already imported what they need and now they import everything?).

  3. If I import the above do I need to import this:
    from pyrevit import revit, DB

  4. Also, when it comes to Transaction:
    Is that okay if I use standard RevitAPI transaction with start() and commit()?
    I noticed that some users simply use with revit.Transaction().

  5. Let’s say, I don’t import something that I need for my script from Revit API, will pyRevit give a warning / error to stop a script? Or there is a chance that Revit model gets corrupted?

Please advise.

2

Welcome @VitalijM,

no use if you import pyrevit modules

basically you should either import the Revit API from Autodesk.Revit or from pyrevit module, but not both.

The pyRevit way would be:

from pyrevit import DB, revit
# then
DB.Transaction
DB.Workset 
# to call on Revit API DB objects

No, you don’t as long as you don’t use any pyrevit specific methods in the revit and DB modules

Yes, it can come in handy to use it the regular way, but the pyRevit way handles the transaction more nicely and with added features when using:

with revit.Transaction('Name of the Transaction"):
    # do stuff

https://ein.sh/pyRevit/reference/pyrevit/revit/db/transaction/#pyrevit.revit.db.transaction.carryout

Yes, you will get the traceback in an output window like this one for example

image
image900×600 25.7 KB

3

Thank you for the reply.

Last question: when I import the below, does it import everything? Or when I call on Revit API objects, let’s say DB.Workset, it only imports whatever I need (Workset Class in this instance)?
The reason I’m asking is that some say that we need to try to avoid importing everything (import * ).

from pyrevit import DB, revit

4

I think in this case, it imports everything, same as import *
DB being a wrapper around the list of RevitAPI DB

5

Interesting questions there.

Why you shouldn’t use import * has to do with a thing called scope.
I’m not going to go too deep into what that means so here’s an analogy.

Imagine you’re working on a lego project, and you have a box that stores all your bricks. (DB)
You are working very clean, and have sorted out all the bricks with different colors and shapes into different boxes inside your bricks box.

If you use a import like so:
from Autodesk.Revit import DB
You’re telling python to look inside the bricks box and get whatever you need.

If you use an import like so:
from Autodesk.Revit.DB import *
It’s more like this
image

6

Thank you. Explaining things as if you are talking to a 5-year old are the best. No sarcasm here.

7

Starting with pyRevit here, was so overwhelmed and confused with where to start, these are some great questions and explanations. Thank you!

8

I keep a boilerplate setup with imports for pyRevit, for Revit Python Shell and for Dynamo. Each is a little different and I often flip between them during development and the day’s weather. Our IT isn’t equipped to manage GitHub and, VisualStudio and lots of libraries, so I keep it as streamlined as possible and use Dynamo and PRS for debugging. And then only using the Python node in Dyanam0 - silly but it isn’t bad for knocking out some code.

When I’ve got something complete - I’ll try and whittle down my imports. Comment out the RPS and Dynamo imports. But some day’s it is just simple to toss it at the office and get back to real work.

1 Like
9

that’s where I was feeling lost, I use ChatGPT to learn and many times it would have different imports and syntax, I figured codes for Revit API, pyrevit and dynamo are a little bit different. I just need to ask the right questions to finally understand it all. I’d love a template setup. It would be a great resource for people like me honestly who rely on self learning.

10

I’ll post something for some very basic boilerplate…
ChatGPT favors Revit Python Shell. So most of the code will run in that environment. It did a pertty good job of digesting everything so you don’t have to do a lot of declarations or imports. But you do have to be aware of the things that are going to go south moving over. For instance, ElementType.Name works fine for me in RPS, but I have to use Element.Name.get(elem) in IronPython for pyRevit. And then I forget abouot it for a month and it bites me again.

1 Like
11

Awesome!

Please correct me if I’m wrong but RPS is not available in RVT 2025? I checked on github and the latest version is 2022. and I have no experience using it.

this is another thing I was struggling with my code giving error trying to figure out what’s wrong. so pyrevit uses IronPython? same as IronPython in dynamo? is there a resource for IronPython code like something I can use as a reference to debug my code? edit : ignore this question, I just did some chatgpt queries and now I have a better understanding of IronPython.

sorry for all the questions and thank you for the patience to answer.

12

That is correct. It was last updated I think in 2022. But works fine on 2023 and 2024. Not 2025 which is sad. Good tool. Our office is only doing a coupe of projects on 2025 and we haven’t needed to move over yet. In previous offices we were always using the latest and greatest. this office lags behind and the bulk of our projects are languishing in 2023. For whatever reason - there is an aversion to updating projects. RPS is solidly IronPython.

Dynamo went CPython, but is now headed the PythonNet direction. I’m waiting for the dust to settle and have code in both IronPython and CPython. Every now and then I think I’ll just go back to C# as everything I do is straight API anyway. but Python is so easy to manage in a small office. Those damn C# semicolons. Only slightly better than counting the billion parentheses of lisp in a DOS text editor.

2 Likes