About project state
LuqueDaniel opened this issue · 49 comments
The project has grown a lot over the past three years, thanks to all contributors, with a special shoutout to @duckdoom4 and @rdurfee.
In the middle of last year, I underwent several life changes that significantly reduced my time to contribute to the project. In addition, I haven't been involved in Ren'Py projects for the past year.
Many users have been using this extension in their projects. That's why in this issue, I'd like to talk about the project's future with anyone interested.
At this point, this is a community project. If anyone wishes to continue maintaining it, we can even transfer the repository.
Also, ping to @renpytom.
Gracias!
Thanks for the kind words, hope you're doing well 🙏
I would love to help again when I find the time. Currently I have work and other personal projects that take priority, but this project is definitely still on my mind. Still have plenty of ideas to implement and continue with the full intellisense like features.
I do have to say that it's a lot of work for just me, so I would welcome any help I can get with open arms
I'd like to thank you for all the work that you've done for this, and for the atom extension before this. I use it myself, and appreciate everything you've done.
I'd like, if possible, to transfer the extension to the @renpy organization, so that I can at least keep the basic syntax highlighting updated in sync with Ren'Py - and if we can improve the grammar, add full intellisense, and so on, that would be wonderful. (But probably beyond what i'd be good at - I'd love it if @duckdoom4 and others could help with that.)
Again, thank you for everything you've done - and for being willing to look out for the project like this.
Everything is going well, thanks!
I think it's a good idea to transfer the repository to @renpy. Maybe it will attract new contributors. If @renpy were to publish the extension, we could deprecate the current one in its favor.
Also, I want to continue helping and contributing as soon as I've some free time 😄
I think that makes sense. Do you want to transfer the repo, or should I fork it?
I can probably also have the launcher handle the migration to the new extension, and I would also like to immediately update the syntax to include new keywords.
And I'd be happy if you keep helping - it's been incredibly valuable to have you handling the extension, so I can focus on the engine.
I can transfer it 👍 Just let me know and I'll do it.
Then it will be necessary to publish a new version of the extension (taking the opportunity to correct the typo in the name languague-renpy 🤣), once published I'll be able to request that the extension I published be deprecated in favor of the new one.
Okay, let's move the repo hosting over to @renpy.
What I'm thinking is publishing a new version now, and modifying the Ren'Py extensions system so it installs the new version - that will end automatic installs. Then in Ren'Py 8.3, there will be a change to the launcher that will uninstall the old and install the new extension (can extensions conflict?).
Done! ✨
You can add the VS API token in the secrets (repository configuration) to make the publishing workflow with GitHub Action work. The workflow is triggered by adding a tag, for example, v2.3.0 (v2.4.0-pre-release for previews). More information:
@duckdoom4 had collaborator permissions on the repository.
Would be awesome if we could still have that, but I completely understand if you'd want all commits to be reviewed before they are merged even on develop
Yep, of course, code reviews should always be a required step before integrating new code (we also have automation to check style and code).
So now this is 'officially' part of renpy, maybe we should check if we can automate some tasks. I remember we started working on some grammar definitions and my intention was to use those to generate the parser rules and AST nodes. That way we would only need to maintain one source. (And probably fix the occasional bugs).
Another option is to use the original renpy parser, but problem with that is the language barrier. I'm not sure how easy it is to execute python code from the extension + the need to output the entire AST state and rebuild it on the extension side.
If anything it might be easier to simply copy the exact implementation and convert it to js. (Which I wasn't comfortable with before, but now it's part of renpy that's no longer an issue :p)
There isn't really a Ren'Py parser, to be honest - at least, not one that conforms to grammar rules. It's pretty close to an LL(k) parser, but there are several places where the Ren'Py parser simply passes everything to the end of the line, or everything in parenthesis, or everything in a block to Python.
So I don't think copying the parser is doable, unless we can shell out to Python in certain places.
I can try and review the code and keep the automation working, but I'm not up on VS code or the automation. Hopefully I can learn.
Okay, I'm finally starting to pick this up again as the next step in getting Ren'Py 8.3 out the door.
As a question - how was renpy.json generated? It looks like it was automatically created from the sphinx documentation somehow - but i can't quite figure out how.
Ah right, I had the same question some time ago. It was made by rdurfee.
I should still have the script somewhere. I can push it to git.
I also have a little bit of time, so I will help with some of the active git issues this month. After that I have another assignment, so don't think I can help much then
Yeah, that script. I don't know if still works.
Thanks, any bit helps. I'll probably take a look at the doc generator script - Python and the Ren'Py docs are both well in my comfort zone, and so that's something I can work with. I'd like to at least get that updated and the first renpy.language-renpy release out, and if we can get anything else taken care of, that would be great.
I was fixing the build errors we magically got on develop. Though with the eslint update we seem to have some more, so wip #411. But at least it should compile now.
Unfortunately I have to go now, so will fix the rest tomorrow.
Also @renpytom, let me know if something doesn't work or isn't clear. I tried to make setting up the dev environment as easy as possible, but would be a nice test to see if I missed something/some instructions
I think the development environment is actually pretty nice. My main issue is with wrapping my head around the design decisions.
Right now, I'm trying to wrap my head around the config/renpy/internal distinction in renpy.json - I'm not sure what internal is for, or why config and renpy are distinct.
Made the first release from the Ren'Py organization, using vsce publish directly.
- It required a few version bumps as I worked through some issues.
- I also had to rename it for now - "Ren'Py Language (8.3+)". This can probably change once the old extension is no longer primary.
- The --pre-release flag was ignored, despite it being suppled. Probably since there was no existing release.
- Had to back out the @types/vscode version update, at least for now.
The good news is the new build is up at:
https://marketplace.visualstudio.com/items?itemName=renpy.language-renpy
So I can work on installing it and upgrading old installs.
Great! I'll request that the old extension be deprecated in favor of the new one. Also, look into what can I do with the extension published on Open VSX.
Made a big update in #414
Fixes some bugs I found and some other improvements. I still think we should try to finish the grammar definition files, as that will help improve the syntax highlighting accuracy.
Let's hold off on deprecating the old extension for the new one for a few days - at least until we get a little experience that I built things right. This is the right thing to do, but I also want it. I'd also suggest that we ask that the Ren'Py Language name get freed up (with the old one becoming Ren'Py Language (deprecated).
@duckdoom4 Seems reasonable.
I'd like to start getting Ren'Py 8.3 out the door, and I'd like the VSCode extension to be at least better than the last version before I do that. I don't have a great idea of what that will take in terms of grammars and so on.
Same here, haven't touched it in a while so will need to re-familiarize myself with the current state of the extension. IIRC I got quite far last time with both the syntax highlighter and the parser. I remember adding support back in to highlight all the screen and ATL language bits.
I think we could just have a look at the 'unit test.rpy' file and check if everything still looks correct + add new renpy 8+ features that might be missing from it
Maybe I can free the name with a last release 🤔
@LuqueDaniel you still have branch fix-149 open. It looks good enough to merge, but I'm guessing you hadn't finished it yet?
I left that PR in draft because I wanted to apply some refactoring... although I don't remember what it was. We could merge it.
So I think I've resolved most of the big issues with the previous version. Now we just have to implement the new features and do some testing and we should be able to publish a pre-release build to get some public testing going
Okay. Any sense about timing, and if this is a good time to cut a release? I'd like to get Ren'Py 8.3 into prerelease shortly, and I'd like it to download the new extension.
Not sure. We used to be pretty loose with pre-release builds, since it was just the two of us who could do the testing. We would usually just go over everything right before and then make a build.
It's why we introduced pre-release, we used to break the extension quite often. With the pre-release we had some public testing buffer
@renpytom Let me know if you're ready to do some testing. I think it's ready enough for a pre-release.
I did do some work to start splitting the code into client and lsp-server (on branch lsp-server). We avoided that for quite a while, but that's the only way to make sure the extension doesn't cause vscode to freeze (since it is ran in a different process). But this is not done yet, and I can't work for a couple days
@LuqueDaniel Could you set the previous version to deprecated in favor of the new version so people will get notified they should update? I noticed it doesn't tell me anything right now
I was waiting for @renpytom to let me know when to deprecate it. If you think that the new version is ready, I can request to deprecate it.
I think we're ready as of a few days ago, unless anyone says otherwise. I've been running the 2.4.0 release for a few days, and Ren'Py 8.3 is now forcing the upgrade to the new version. (It's not released yet, though.)
All right, deprecation is requested!
Thank you. Once that's in, I'll email them and see if they'll free up the name.
I think we're ready as of a few days ago, unless anyone says otherwise. I've been running the 2.4.0 release for a few days, and Ren'Py 8.3 is now forcing the upgrade to the new version. (It's not released yet, though.)
Have you noticed any issues so far? I do think we'll need to update the syntax highlighter to support any new renpy 8.3 syntax/features. Though it might (appear to) work if it uses previously used keywords since I build in fallbacks
The only thing I've noticed is a few missing style properties that were added, which I'l look into adding. (So far, it's the box_justify and box_align properties, which I added after 2.4.0 came out.)
Any suggestions as to if this should go directly into 2.4.1, or if we should have 2.5.0 followed by 2.6.0? My first inclination is that porting over Ren'Py syntax changes could happen in the stable branch, but I'd like feedback on this.
Some changes to the syntax highlighter are probably fine to go into main. But my experience with it in that past is that sometimes when I fix one bug, another is created (pesky regex patterns). So I tended to do any syntax highlighter changes on the develop branch, use it for a couple of days, and if I didn't notice anything broken we'd make a pre-release.
Then after we were sure we had a stable build, (which we based on how quiet the issues section was XD) we'd push to master and make a stable release.
We'd usually do increments of 0.0.1 on pre-releases for small changes that don't affect the usability, and 0.1 increments if the changes were important enough.
But I'm open to any changes to this ofc.
@renpytom Would you mind also taking a look at the grammar files to see if they are still accurate?
I know it's still incomplete, but would be nice if the things that are defined stay up to date
I'll run this pass after I make the 8.3 prerelease (maybe today or tomorrow, but certainly this weekend).
Deprecated!
