Future planning

[duckdoom4]

@renpytom would this work for you?

@LuqueDaniel would you like to still be included in the conversation?

[duckdoom4]

Also @renpytom, I noticed the pre-release wasn't added to GitHub. I suppose that's because you did it manually instead of using the workflow right?

@LuqueDaniel would you be able to update the workflow so it works for the new marketplace link?

[LuqueDaniel]

Yeah I can tweak the workflow

[LuqueDaniel]

Sure, I want to stay involved (I usually look at changes and issues when there is a notification).

[matracey]

@duckdoom4 Since I'm working on these PRs - #497, #498, #499, #500, #501 and #502, with several more that I have planned after these, I wanted to ask a few questions on the current state of the release process / cadence.

• What is the current "releasability" status of the project? Can a release be triggered on GitHub and be automatically published to the VS Marketplace and Open VSX? Have Update publish workflow #452 and / or Request to Publish Extension on open-vsx.org #490 been addressed or are they still pending?
• I assume master releases the stable extension version and develop releases the experimental version, is this correct?
• The latest GitHub release is v2.4.0, dated as 2024-07-29. The VS Marketplace is also showing the latest release as v2.4.0, however the last updated date shows 2025-03-22. Is there any cadence with which the extension releases against? Wondering if it aligns at all with renpy/renpy since I know the extension is bundled in with the SDK?
• There are some commits on master since the last release was published. Are these ready to be published as v2.4.1 or v2.5.0? Could this be released this week or next?

I'm open to help as an external contributor in any way I possibly can with anything blocking automated releases, so just let me know what I can do.

[duckdoom4]

What is the current "releasability"

That's handled by @renpytom. I'm uncertain about the current workflow/status. As far as I know we don't have the package on Open VSX right now (though we used to before the move).

I assume master releases the stable extension version and develop releases the experimental version, is this correct?

Yes, that is correct

Again, not sure. @renpytom might be able to answer. We used to have an automated workflow that pushes a new release when we create a new version tag.

There are some commits on master

Those are just dependency updates. Not super important to push that change. I think we should wait a bit longer until we have some new stuff/fixes on the development branch before we push a new version.

so just let me know what I can do.

One thing I've been working on (and got quite close to completing) is the custom renpy parser. With just a bit more work we should have a fully functional tool that allows all the fancy code editor features to be added (like proper go to definition, variable highlighting, semantic highlighting, printing live errors etc.)

I was also looking into setting up a language server on this branch. See documentation here. This would solve the long standing issue about 'high CPU usage' and the extension causing vscode to freeze, since that would allow us to run the file parser/tokenizer on a different thread. This should also allow us to import the python lsp so we can enable that for python sections.
(Though we might just want to use our own parser to parse python source, since renpy runs on slightly custom python)

But those are just things I was working on. Please feel free to pickup anything you find interesting. Any help is more then welcome at this point and starting small is probably better to get going anyway :p

[matracey]

Thanks for clarifying those points, @duckdoom4.

What % complete would you estimate the parser is? Was there any particular challenge that you came up against which paused the work, other than available time to work on it?

I'd be interested in trying to finish that work on the parser once I finish with my goals of adding unit tests for the existing codebase and adding the "F2 Rename / Refactor" provider.

Setting up the LSP would definitely be a much more involved project, but ultimately a very worthwhile one, I'd imagine. I think this could be tackled once the parser has been implemented, and I also think the LSP service could benefit from being its own repo within the renpy organization, which could subsequently enable extensions for other IDEs like PyCharm.

[duckdoom4]

True, sound good. I think I had some documentation somewhere. Let me try to find it and ping you there.
Edit:
Ah no, that was for syntax highlighting. In that case, let me make a new one. I know I taked about it with other peope, so should be able to put together a document quickly

[duckdoom4]

Okay, I've let AI generate a summary of the conversation I had with someone else about this. It's part of a new discussion thread.

I also tried to update the parser branch to develop, but I noticed the extension fails to start due to some weird stack overflow. Unfortunately I ran out of time for today, but I hope to fix it later.

[duckdoom4]

Small progress update on this. I've imported all the fixes/changes on the parser branch in shared code over to the develop branch, then I did another rebase and patched up the commits over there.

I also fixed the stack overflow. ~5 months ago, I let AI generate the python parser rules from the EBNF, and it did a bad job. So now I let AI fix the issue and that seems to have fixed it. I should go over the rules manually, but I don't really have the time for it right now XD

In other words, be aware that the python rules may be very bad. The renpy ones I did myself, so those should be used as reference.
On that note, I added the documentation here (in case you didn't find it yet): #507

[renpytom]

I think I kind of need help with all of this, to be honest. I don't have a great idea of what the workflow for vs code extension releases is - but I do know I'm not doing a great job. Suggestions on how to improve things would be very welcome.

I'd like to release the develop branch in the next few days, so that it matches some of the new syntax and so on. It might also make sense to try and restore some of the automated workflow for releases, to make those easier.

I'd also eventually like to flip the branches to be what Ren'Py uses - a main branch that development takes place on, and a fix branch that cherry-picks fixes.

[duckdoom4]

Sounds good. I hope @LuqueDaniel answered some of your questions :)

[matracey]

Thanks @LuqueDaniel - appreciate all of your work on this extension to date! 🍻

Rather than commenting it out, I'll just add a check that the VS_MARKETPLACE_TOKEN is set. I'll do the same for the OVSX_TOKEN in the OpenVSX publish step. That way, whenever the token does get configured in the repo settings, the publish to both marketplaces will work immediately without any need for additional PRs.

[matracey]

I think I kind of need help with all of this, to be honest. I don't have a great idea of what the workflow for vs code extension releases is - but I do know I'm not doing a great job. Suggestions on how to improve things would be very welcome.

I'd like to release the develop branch in the next few days, so that it matches some of the new syntax and so on. It might also make sense to try and restore some of the automated workflow for releases, to make those easier.

I'd also eventually like to flip the branches to be what Ren'Py uses - a main branch that development takes place on, and a fix branch that cherry-picks fixes.

@renpytom The workflow will handle publishing the extension to the marketplace as part of the release the once the VS_MARKETPLACE_TOKEN and OVSX_TOKEN secrets have been set in the repository settings.

I do have some changes pending to merge for the workflow which would allow a release to move forward with just the VS_MARKETPLACE_TOKEN token for now if the Open VSX setup is too much.

All that needs to be done to trigger the release is create a new version tag (i.e. git checkout develop && git tag "v2.4.1-pre-release" && git push --tags) which would kick off the workflow.

To streamline the Open VSX setup, @duckdoom4, if preferred, or I could handle the setup for publishing the extension on Open VSX, add you as an owner of the "renpy" Open VSX namespace, and then you could just generate the access token which gets added as a secret to this repo, if that would be helpful?

Open to helping out with this extension however I can, so please let me know how I can help.

[duckdoom4]

That would be up to renpytom, I think it would be better if those tokens/accounts are in his control.

[matracey]

That would be up to renpytom, I think it would be better if those tokens/accounts are in his control.

Yes, I definitely agree. All tokens and accounts would be under renpytom's control in the end. I'm just proposing that someone who is familiar with the extension codebase and CI/CD pipeline can take the time to set up the extension in Open VSX and then "hand over the keys", so to speak, by transferring ownership of the Open VSX namespace to renpytom.