New Plugin System #3
Comments
maforget
added
enhancement
|
I like the idea of modernizing the plugin system, but the fact that the plugins are written in an accessible scripting language is helpful in the case of abandoned plugins. Being able to hack on the plugin locally without much friction to the user (outside being comfortable with the language) is really useful. Moving to a .NET assembly approach works if the source is available, but now requires a compiler toolchain rather than just hacking on the local script. That said, I don't have a ready solution... so maybe ignore me. :) |
|
Problem is that even with the existing IronPython script a lot of objects are .NET object either way. With the actual tools you don't have access to the actual objects property. So for example in a IDE you don't know what the book objects contains like property and what information you have available. The only way to actually check what the data it has is to debug it with tools that aren't really made for that. That makes creating plugins & debugging them really really hard. Unless you do it via trial & error and just print some stuff to debug, you would have needed tooling either. Also Visual Studio Community or Visual Studio Code are free, but I understand that not everyone likes that. But at that point they are really firing themselves in the foot without one. Going full .NET would just make creating and debugging plugins so much easier. That said it might be possible to have just the .cs file loose and the program could compile them itself. Don't know how easy it would be, but I did see it somewhere in the past. Might help prevent against harmful software and easier modifying. But you would still probably need the tools to create them. |
|
I don't use python but I think python is a language more popular for no developers, maybe have 2 kind of plug-in system to don't close the door for python enthusiast |
|
That's the thing we can't use Python. It isn't a matter of popularity, IronPython is dead. It as 0 support in IDE's, I still need to keep around a 2017 version of VS, just to check plugins. The new VS won't even acknowledge the python interpreter if I setup it up with it. Current tools to are nonexistent. The current version is based on Python 2.7 which is long dead. There is a new version 3.4 that was release last year. But support will probably not be better. And like I said the objects that are passed like the books are .NET object. So the python script needs to understand these objects and that is IronPython. The main reason python is popular is because usually when learning programming people start with it. They start with it, because a lot of things are taken care by the interpreter. It's easier, you don't really have to care what type that method be returning while assigning that variable. But the object type do still matter, you just find out when the program crashes with an error message like: was Expecting int, got None. I have a lot of difficulty with python because of that. You don't really know what an object capabilities are when doing something like a plugin. You have a books or an App object that are is returned by CR, but no documentation that the App object could say call With proper C# plugins, all that goes away. Because you know in advance what is the type of an object and what you could do with it. So you get the error at compile before hand. It's a little bit harder, but really not that much. Since we need to work with .NET objects anyway we might as go with full .NET scripts. Also I have 0 intention of removing the current Python plugin system, there are way too many irreplaceable plugins that use it. |
|
I totally agree about Iron Python. What do you think then Python.net? |
|
If it is based on Python 3 then it can't be used either, there are big chances that it is. A lot of existent plugin would break. If only because they use I get that Python seems simpler for the non-developers, but I doubt that Python.Net as better support in IDE, like the points I enumerated earlier. Debugging, Intellisense, etc. Shockingly, this would make a non-developer life, way easier than without these tools. I've seen countless post on Reddit about starting devs that don't even use the debug function and inspect the properties of an object, when it would help them a lot. But like I said, the existing python plugins aren't going anywhere, those who want to can just use that still. I just really want a proper Plugin system. |
|
I understand what you are saying and the truth is that you are very right, there is a lot of written code that it would be a shame to lose it. |
|
I don't think PowerShell is more friendly than Python or C#. I am personally not really used to it, and find it harder than C#, since I don't know the cmdlet or syntax. But I don't think that using PowerShell instead of the proposed .NET plugin system will happen. And it will certainly not be easier than C#. Maybe like a script that could be written like it works in Playnite. They have full .NET plugins, and you can use script in PowerShell to do Pre or Post Script. For example I have one for the Yuzu emulator, that will start the maintenance tool, so it is updated before loading. In that sort of situation or like an automation macro that someone mentioned on reddit, sure. But it will never replace the plugin system. I really don't see the problem, if non developer really wants to do a plugin they can try with C# and if they find it really that hard, they can do Python, since it's staying. But really there is not a lot of difference between both. The reaction is surprising, because it seems like I am taking away something really easy to change it for something really hard. Which isn't the case, Iron Python will be staying and I believe that a new plugin system will be easier even for non-developers. |
I wonder if the reason for the reaction is the introduction of compiling as part of the plugin development process. Python is interpreted, which makes it easy for non-developers to build and test plugins. Needing to install Visual Studio and figure out how to get things to compile can be daunting and requires more technical understanding. That's not to mention learning new syntax, dependencies, etc. I am much more likely to invest time in creating plugins for systems using interpreted languages like Python and Lua because I can get set up quickly and iterate without delay. I make a lot of little mistakes when learning something new, so compiling can be a pain sometimes, even if it's quick. As someone pointed out earlier, interpreted languages are also easier for people to mess around with to fix problems after a developer disappears. I've seen a lot of this with ComicVineScraper as people send code snippets back and forth. I also think people are assuming the Python support will eventually drop away. Based on the discussion so far, I think that's still likely eventually as it sounds like IronPython will lock development to the latest .NET that it will function with. I've seen this happen in the past, so I understand people being hesitant. Some of the hesitation might be assuaged by providing good documentation of the plugin development process with whatever the new system uses, resources to make migrating plugins less daunting (a robust preset GitHub workflow for compiling, for example), and long-term support of the old IronPython system. I'm happy to help with this part wherever it's useful. |
|
Perhaps what would be convenient is to make some specifications of what you want about the plugin system and those of you who are in charge of this project can decide. |
|
What about something like dotnet-script? It is available for the newer .NET, but is pretty much like using python, but using C#. You can import NuGet package with a single line. Don't know if would be possible to hook it up and use it like a plugin system. Maybe as an alternative to IronPython if we can't use it with a newer framework. For the normal plugin system I am proposing. I also like the idea about not needing compilation of files. It could be done on the fly when starting a little bit like it exists with the current IronPython system. The idea that file can be easily modified in the future if the source isn't available anymore and the better security you can have by actually checking the code that is ran (it is possible either way, but easier and prevents obfuscation). |
I think it's a good solution |
|
What about using powershell? It should already be installed on any system you'd install CR onto. |
Already mentioned above. see my response: #3 (comment) Going Powershell would be a really big hurdle for newbies. I know some have created forms with powershell, but compare that to using Visual Studio to create a UI, to powershell or even IronPython (I had to build an old version SharpDevelop to do it, but it's mostly done by hand). I get the attraction of python vs C# it's better for beginner, but powershell ain't that for them. I think most would prefer using C# with a good IDE and have all the tools like Intellisense and WYSIWYG for building. But like mentioned in the other comment, for a kind of scripting or macro language, than yes 100% for powershell. |
|
Just posting info on compiling C# code inside C#: https://stackoverflow.com/q/62523946/439152 A possibility would be to have loose .cs file that would be compiled by the program on use. |
We need to replace the existing obsolete IronPython Plugin system. I would keep it as is for Legacy purpose, but create a new system that would live alongside the IronPython one.
P.S. The Current 2.7.4 version of IronPython that is installed seems to be the last one that will work with existing plugins. There is a version (at this time 3.4.1, updated in July 2023 that might be an idea).
But I believe the easiest is just to do a plugin system using .NET. Having dll in the folder instead. All they would need is probably just an Interface that they would need to implement that would serve as an entry point. Would we need to have various types for the different Hook that current plugin permits? Or maybe use Attributes to specify the Hook Types?
Could we also use something like HarmonyLib to give plugins an even bigger access to the entire code, to be able to be changed on the fly.
The text was updated successfully, but these errors were encountered: