Repository navigation
Can this be made to run in a container? #241
Description
The python requirement is likely a dealbreaker for both dev machines and on CI. Makign this into a container would at least make it possible to run this without needing a developer's machine (esp. our 3rd party devs) to have python available. Thanks!
Activity
karthiknadig commentedon Jul 13, 2023
We can certainly create a container. But, can you elaborate on this. What in particular about python does not work for you? Python is available to install from Windows store, and most non-windows OS ships with python. Most CI, including Microsoft secure release CI includes python. Python is available on nuget as well: https://www.nuget.org/packages/python/3.11.4 . I would like to understand this limitation better.
CyrusNajmabadi commentedon Jul 13, 2023
It adds a painful additional step that has never been required to develop roslyn before. It's also well outside the wheelhouse of .net development. It would be like us saying that to develop roslyn you need C++, JavaScript, or any other lang unrelated to .net.
karthiknadig commentedon Jul 13, 2023
To make sure I give you the right experience, can you explain exactly how to expect to consume code from this project?
This is how we intended this to be used:
[Option 1]: We generate C# code, test and validate against our test set and any smoke tests. And your CI can pull the generated code from known location from this repo. No python needed on your side for this.
[Option 2]: We generate C# code, test and validate against our test set and any smoke tests. We create a PR on your repository with the updated code. No python needed on your side for this.
[Option 3]: You have a cron job in your CI that monitors LSP sepc. Run this tool in your CI and the generated code is consumed directly in your repo. This option needs python.
We are flexible to make this as seamless as possible. So let me know how you intend to use this.
CyrusNajmabadi commentedon Jul 13, 2023
So thre's a discussion outside of this happening right now. We shoudl check in with Jose. My understanding is that we're going to move to a model where these generated symbols will be packaged up in a nuget package that roslyn can just reference. This would include an open source library for just the pure LSP messages, and potentially some other library for the LSP++ messages.
karthiknadig commentedon Jul 13, 2023
From what I understood of the previous conversations about this few weeks ago: The opensource pure LSP library will sit in its own repo (or with other code, but a repo. It can be anywhere). For the code generation for that repo you will use either of the above options to get the code into that repo. For bugs in code generation, they will be handled by us. Since, we will have to apply the fix for all languages that get impacted. So, for developers working with Roslyn who consume the opensource pure LSP library I don't see the need for installing this generator, so no need for python. It is not expected/intended that the generator will be run for each build, only when there is change to LSP spec or bug fixes in code generation. Unless developers are trying to fix a bug in code generation, I don't see someone would need to install this tool.
We can discuss this in detail in the next LSP sync. It looks like we might not have all the context.