You probably visited once the pyrevit repository on github and noticed the 250+ issues still alive yesterday
Hard to keep track of all bugs and issues, understand them and fix them to make pyRevit a sustainable tool for Revit and more.
So we (@eirannejad and I) closed issues older than a year or so. Some were irrelevant, some undocumented or stale.
If some of them are still relevant to you or the community, feel free to comment tagging me and I will open them again _ but please, give it some love: detail the issue or request, add images and relevant code or references.
That being said, help would be greatly appreciated in fixing the 42 issues that are still opened as of today.
If you feel up to the task, raise your hand, take an issue and get to fixing it:
Fork the repo,
Create a branch from develop branch with PR/issue number
And get to code and test it
I will post some easy to fix issues or feature request in the coming days so that we manage to get the issue count to a minimum
iāll take a look at the issues iām only a beginner at this and still learning a lot.
But the work you guys did with Pyrevit is amazing i want to return the favour!
Canāt promise to much but iāll give it a shot a see where i can contribute .
Hi @Jean-Marc ,
While I totally understand why, Iām not convinced on how you āsolvedā the issues by ignoring them.
A better approach could be done by usig some automations such as the close stale issues action that marks as stale the issues older than a predefined duration and closes them after x days if no activity is done around the issue (a simple comment would reset the timer).
Maybe, but only Ehsan has the necessary access and is not so much available.
We were trying to release the version for Revit 2024 the other in a working session. And just fixing the repo to work with the revit api changes took us 4 hours and we were not done.
So at one point, hard decisions were made. Everything is possible, but we all have a life and a job, and the number of people fully involved in the fixing of issues is extremly limited.
Only 4 people reacted to the 200 issues I closed without solving. I reopened the one that made sense.
Not all issues are equal, some require hours and loads of refactoring.
You can join forces and take 1 issue a day or a week and fix it @sanzoghenzo
Like I mentioned many times on the forum, feel free to join the effort.
I did my best at solving my own issue!
I introduced the new optional argument sort_groups to the init.py file, added it to the description and to the example, raising a PyRevitException for wrong input. Everything works as expected.
Now my problem is that I really have no idea how github works, your description in the starting post is not detailed enough for me to understand
So please tell me if I can do anything more to help!
Full code posted in the thread below.
class SelectFromList(TemplateUserInputWindow):
"""
Args:
.......
sort_groups (str, optional):
Determines the sorting type applied to the list groups. This attribute can take one of the following values:
'sorted': This will sort the groups in standard alphabetical order
'natural': This will sort the groups in a manner that is more intuitive for human perception, especially when there are numbers involved.
'unsorted': The groups will maintain the original order in which they were provided, without any reordering.
Defaults to 'sorted'.
Example:
>>> from pyrevit import forms
>>> ops = {'Sheet Set A': [viewsheet1, viewsheet2, viewsheet3],
... 'Sheet Set B': [viewsheet4, viewsheet5, viewsheet6]}
>>> res = forms.SelectFromList.show(ops,
... multiselect=True,
... name_attr='Name',
... group_selector_title='Sheet Sets',
... button_name='Select Sheets',
... sort_groups='sorted')
There are plenty of article regarding obscure names like: forking, rebase, clone, ā¦ so I wonāt add to that ocean of knowledge.
If I sum up a bit more clearly, whatever the tool you are using (VSCode, githubDesktop+VScode, pyCharm, ā¦):
fork the repo (create your copy of the repo under your own user)
checkout a new branch from the develop branch (from the original branch on Ehsanās version of the repo)
make your changes in that branch
1.you may want to attach this āclone of pyrevitā to Revit to test it. Thatās where pyRevit CLI is useful: pyrevit clone --help to get the isntructions on how you can create the clone from your copy of the code, but you will want to use pyrevit clones add <clone_name> <clone_path>
2. pyrevit attach NameOfYourClone 2711 --allusers --installed to attach your clone to Revit
make a PR to the develop branch of the original pyRevit repo (not your own fork, but your modified version from your fork againt Ehsanās develop branch)
add more commit to the PR (you can keep on editing the code, and commit the changes and it will automatically commit to the PR
once someone gets the chance to test it and notify me or Ehsan, I can merge the PR and it will be processed by github. The CI-CD kicks in and create new wip installers
if you are done, you can re-attach the regular install of pyrevit using pyrevit attach master 2711 --allusers --installed
Thank you very much @Jean-Marc for taking the time to explain, i can now see a tiny light at the end of the github tunnel
If github crashes in the next days it was me, sorry in advance!
And now IĀ“m confused because you sayd that i should checkout a branch from a branch from Ehsan. But I did just checkout the dev branch in my own clone, i thought IĀ“m going to work on my own clone.
And i donĀ“t understand ābuild the projectā, do i really have to install all this that is mentioned in the help file:
<b> * Requirements:</b>
Install these tools before starting the build process. Add the binary
directory for these tools to your system PATH. Run `check` to test
dotnet SDK for building labs (https://dotnet.microsoft.com/download/dotnet)
Visual Studio: for building labs (https://visualstudio.microsoft.com/downloads/)
āāā msbuild building msi installers using Wix Tools
āāā certutil managing signing certificate
āāā signtool digitally signing binaries
gcc for building sqlite package in telemetry server (http://mingw.org)
go for building telemetry server (https://golang.org)
Inno Setup Compiler for buidling installers (https://jrsoftware.org/isinfo.php)
āāā iscc buidling installers from scripts
choco for building and publishing choco packages (https://chocolatey.org)
nuget for signing choco nuget package (https://www.nuget.org/downloads)
Wix Tools for building MSI installers (https://wixtoolset.org/releases/)
pipenv for managing python virtual envs (https://pipenv.readthedocs.io/)
python 2 for building docs (https://www.python.org/downloads/)
python 3 for the build tools (https://www.python.org/downloads/)
pygount for counting code lines (https://pypi.org/project/pygount/)
git for creating release reports (https://git-scm.com)
docker for telemetry server tests (https://www.docker.com/products/docker-desktop)
Starting from where you left, checking out the dev branch.
You need to build the project only if you change something in the csharp code base
Creating a specific branch to work on your changes is good practice.
create a branch from your dev branch with a name that make sense (ehsanās has a page on notion that explains the naming convention he wants us to use)
you can create a PR right after your first commit onto ehsanās dev branch.
Side notes:
If it is a draft, meaning you are not done you will need to indicate it.
You can keep on adding commit and they will automatically be added to the PR
Use the git extensions of your code editor to interact with the repos, it is much easier
.
