submitting code to DynamoRevit repo

image by archi-lab

With the Dynamo 1.3 release, there was also a new version of DynamoRevit tools that were released. Some of you might already know this, but DynamoRevit is nothing more but a Dynamo package that is being created, managed and released by the same people that bring you Dynamo. It’s not really part of the Dynamo core functionality but rather an external package. It has it’s own separate repository on GitHub, and if some feel brave enough, are free to submit code to it. That’s exactly what I want to talk about here but before we get there a few things I want to touch on.

First and foremost: Why? Why, would you want to submit code to someone else’s repository. Especially for someone like myself, who owns a technology consulting company (archi-lab, llc), and pretty much makes money from writing code for $$$. Wouldn’t it makes sense for me to want to at least publish code under my own name, rather than posting it to Autodesk’s repository? Why now just take all the credit and drive my package downloads through the roof? I don’t know, but I am not the only one asking these questions. We all have a different agenda, and reason to do what we do. Let’s take this guy for example:

You might think that creating a Dynamo Package Store is a really bad/good idea…and even said so in the poll above (pretty split there). I am not exactly sure about it either, but a paid for “store”? It’s just not what I am interested in. Of course I like the idea of actually getting paid for my code, but I am not sure that a “paid for packages” are the right idea for this product/community. Some of you might be rolling your eyes now, thinking that I am sort of Dynamo freedom fighter. No, not at all. As a matter of fact if you believe that Autodesk doesn’t have $$$ in their mind when they are allowing their developers to work on semi-free (Dynamo Studio is paid for), and Open Source Dynamo, I suggest you pull your head out of your arse now. I just don’t think that selling packages, makes sense in a Open Source community and for an Open Source product. I think that developers that want to work on these, should be paid for their time, but nodes that they develop should remain Open Source and if they are funded by the community, rather than individual companies/people then maybe we have a viable solution for keeping everyone happy. Take for example my Mandrill package, and amazing community response to fact that it needed funding. Granted, $1,000 bucks doesn’t pay for my time, but I think it was a great, albeit small sample of a viable community funded, Open Source development. If we can scale that up…who knows?

Now, how does all of this tie back to what I wanted to talk about originally? Well, if we are to collaborate/create our own tools, we need to know how. Here’s a few steps on how to get started:

  • Read my original post on how to clone DynamoRevit repository and build it from source.
  • If you have it downloaded, then you can simply create a new branch for whatever fix/change you want to submit. If you go to the second tab called “Team Explorer”, it should have listed whatever branch you pulled down. In my previous post I suggested pulling down Revit2017 as that was the latest Revit version that DynamoRevit was built against, but you can of course now pull down Revit2018 or any other version.

  • To submit any new code or code fixes to the DynamoRevit repo, you need to create a new branch. You won’t be allowed to submit things straight into the master branch, or even the Revit2017 branch. Right click on the Revit2017 branch, and create “New Local Branch From…”. That will create a “copy” of codebase that currently sits on that branch and check it out for you to make changes. Give it a descriptive name, but short. Also, before being able to submit a new pull request for this branch later, you have to make sure to Publish it. Click on Publish Branch after you have created it. Once published it will be grayed out, like on the image above, but it should be available when you first create it. Let’s look at fixing one of the bugs that I noticed in the 1.3 version and posted here: View.SetFilterOverrides Issue
  • Most of the DynamoRevit nodes that are ZeroTouch based will live in the RevitNodes assembly. Here’s the troublesome code:

  • The issue I posted is in the fact that the input port has a name “hide”, so you expect the default to be false, as in you want your filtered elements to be visible. That’s indeed what the default value is, but it actually hides the filtered elements when set to false. Let’s either change the name to “visible” and update the default value to True, or just flip the values. I tend to like the idea of just changing the name of the input. Let’s see what the Dynamo team will say about that. So my changes are these:

  • This was a really small fix so I would probably throw a few more things into it before submitting it, but for the sake of simplicity I will just submit it like this. There is a fine line between submitting too small of a fix, and too much of a fix. Normally you want to keep each Pull Request (PR) to a single task or block of code so that for someone reviewing it it’s easy to grasp what changed. Too many things scattered around, and you will make your PR really hard to review. This functionality lives in the View class, so if there were more View related changes, I would just submit them together, but make a new PR for anything that deals with something like a change to Element class. Before submitting your code, please make sure to test it. This is a really small change so no Unit Tests are needed, but you should Build your solution and try it out before submitting.
  • After you build your solution, the DLLs will be placed in whatever directory you cloned the DynamoRevit repo + \bin\AnyCPU\Debug\Revit_2017. From there I know that my current change was only to RevitNodes.dll so that’s what I will grab and copy into my C:\Program Files\Dynamo\Dynamo Revit\1.3\Revit_2017 directory. I also made changes to description of the input port and its tooltip. That information is stored in a XML file that gets generated when DLLs are compiled. You can copy the RevitNodes.xml from \bin\AnyCPU\Debug\Revit_2017\en-US to C:\Program Files\Dynamo\Dynamo Revit\1.3\Revit_2017\es-ES. Fire up Dynamo and see if the changes worked. It looks good to me:

  • Here’s how to submit your code.

  • Go back to your Team Explorer tab, and switch it to Changes. This is the menu that you can use to submit code to the repo. Type in a short description, and hit Commit and Push. Now navigate to GitHub DynamoRevit repo website and you should see this new option available:

  • Now, you can click on Compare & pull request to complete the necessary steps for this submission.

  • First you want to make sure that you are comparing your branch to a proper branch in the DynamoRevit repo. Since we created our branch from Revit2017 branch, that’s what we need to compare against.
  • Next we give our PR a descriptive name.
  • Explain what the PR is for, what it fixes or adds to the repo. If you made any UI related changes, please post screenshots of what was changed. If it’s a fix to a reported issue, please post a link.
  • Each PR will be reviewed by someone on the team. I usually CC Mike here, but others might be involved. Once you create the pull request you will get this window:

  • Declarations are just series of checkboxes that you are supposed to make sure you checked.
  • First one is just a quality check.
  • Standards are just some code formatting, naming etc. rules that you are supposed to follow to keep the codebase consistent. There is a link next to it, so I am not going to explain this here. Please read it. There will be people reviewing your code, so if you don’t read it, and submit some weirdly formatted code, they will reject it.
  • Testing is what I have mentioned above for the Unit Tests. Since this example only fixes a very small bug, there is no tests needed. However, when submitting new functionality, like let’s say a node that creates a 3D view, you will also need to submit a Unit Test for it, and possibly a test Revit file. More about that in the future if anyone asks.
  • User facing strings are things like custom error messages. If you are putting in something that might pop up on the node, and be seen by the user, then put that string into a resource file. Why? Because Dynamo is being published into multiple languages, and that’s the only way to ensure that all user facing strings are localized. Again, I can amend this post with some examples if needed.

That’s pretty much it. You have submitted your first PR. Normally there will be more work to be done, since you are not likely to submit a PR that has an input name change in it. You will probably have to deal with unit testing and resource files. Just let me know if you run into these, and i will try and post more here. Also, we only talked about a PR that addresses a change to Revit2017 branch. Remember that Dynamo developers are also maintaining branches for 2016 and 2018 Revit so you might have to “cherry pick” the changes into these branches as well. So far Mike has been kind enough for me to handle that whenever I was submitting my code, so I can’t really speak to that task, but I can probably sort that out and also post here if needed.

I hope this helps. Cheers!

Ps. If you were wondering about my last Dynamo Package update, and specifically why there wasn’t any new functionality, then hear me out. It’s not because I all of a sudden got lazy or decided to not develop that package any more. No, instead I decided that it’s better to pull functionality from my package and push it to the source code. Why? As popular as my package might be, it will never be as popular as the Dynamo itself. That means, that my code will reach EVERY user, and will potentially make your life easier without the need for you to hassle around the Package Manager looking for my stuff. It also means that it’s available for Revit 2015-2018, and it means that it will never go away (even when I get bored with it), because that would mean that Dynamo has gone away too. What’s not to like?

Support archi-lab on Patreon!

Leave a Comment