With the change to WowUp, you can now have it install addons directly from a URL (Like GitHub!). https://wowup.io/guide/get-addons/overview

The only issue is that it is looking for a release asset in the branch (Im guessing it doesnt just like Tags).

I saw on the parent repo you were possibly trying to publish so this could be an easy way to add your fork for now.

Yep I was mostly waiting on permission from the original author before formalizing any release. I would also need to do some rebranding. I'll give it a few more days to hear from him before I move forward.

Any chance you've got an update on this? I check this fork a few times a month to make sure i've got the most up-to-date version, but if WoWUp could check it would be much simpler.

Sorry, not yet. It's less of a technical holdup and more of a legal one. The upstream project is All Rights Reserved, which technically means without express written permission I can not legally host a fork on Curseforge or WoWUp. I've emailed the author, and he hasn't responded thus far.

Edit:
Perhaps I'm mistaken:
"If you want to reuse my code, i am also fine with you forking this addon and tuning a little bit here and there. I released the addon on Curse with Creative Commons Attribution-NonCommercial 3.0 Unported, so do whatever you want, just put some attribution if you want to comply with the licence"

I saw this response from Varren in a comment to another person's question.

Aight my version, named DevTool, has it's first release out v1.0.1, and is up on Curseforge and Wago. (It might take a minute to get approved on Curseforge, if you don't see it).

So I'm making good headway on this!

I had only meant to start rebranding to a the new name of "DevTool" which I've been toying with, but I ended up going on a performance and stability sprint. The original version of this addon used a bespoke linked list data model for storing the active data in the main window, and unfortunately it was pretty fragile and did not scale well into the tens of thousands of nodes, such as when you are viewing _G. I tried fixing the linked list model, but it ended up being much cleaner and more direct to just store the data in a table structure. Likewise, doing this changeover + some well needed optimizations yielded something like a 98% decrease in CPU load with _G loaded while actively scrolling up and down the window. Also, we now free up memory immediately when we clear the workview, which keeps the addon from ballooning out of control. The most I can hit now is about 25MB when loading _G, wheras before I could easily get into the hundreds of MB if I had repeat opening and closings.

So good new all around. It will be easier to maintain going forward, as we have way less custom code now. And we have massive CPU and memory improvements.

So I'm making good headway on this!

I had only meant to start rebranding to a the new name of "DevTool" which I've been toying with, but I ended up going on a performance and stability sprint. The original version of this addon used a bespoke linked list data model for storing the active data in the main window, and unfortunately it was pretty fragile and did not scale well into the tens of thousands of nodes, such as when you are viewing _G. I tried fixing the linked list model, but it ended up being much cleaner and more direct to just store the data in a table structure. Likewise, doing this changeover + some well needed optimizations yielded something like a 98% decrease in CPU load with _G loaded while actively scrolling up and down the window. Also, we now free up memory immediately when we clear the workview, which keeps the addon from ballooning out of control. The most I can hit now is about 25MB when loading _G, wheras before I could easily get into the hundreds of MB if I had repeat opening and closings.

So good new all around. It will be easier to maintain going forward, as we have way less custom code now. And we have massive CPU and memory improvements.

Is the new table approach going to lead to key collisions? I feel one of the best ways I've used VDT was to dump a table, do something, then redump the same table to observe the changes. I haven't necessarily reviewed the changes much but figured I'd see if that was considered since it'd be cool to have both a more opimized tool but still retain the previous exellent debugging functionality.

@srhinos If I coded it correctly, it shouldn't. DevTool interacts with and identifies the table based on the unique table hash id, so as long as no two tables have the same hash id it shouldn't be a problem. And I cannot think of a reason it should ever be the case that two tables end up with the same identifier, as those are created internally by the Lua interpreter itself when the table is created. If that ever were to be the case we'd have MUCH bigger problems than table collisions ;-).

I would love someone to look over the code though! Any help or assistance is greatly appreciated. My chief goal has been to simplify the structure and functionality to decrease the barrier to contributing as much as possible.