main repo is incomplete

[Nicholas-Schaub]

I submitted a PR recently and noticed that a bunch of rewrite code as implemented in the main repo. It breaks a lot of functionality, which is fine, but there is no replacement for much of the previous functionality. For example, it was possible for me to add in extensionDependencies when initializing the Extension object. Now you cannot do that, and you cannot set the version either. I understand breaking things when major versions change, but to have only a partial implementation of some of these things in the main repo is usually bad practice because this makes me resistant to work on any new contributions since I am losing functionality when trying to implement fixes or features.

Do you have a list of features/functionality you intend on implementing? I am happy to help implement some of this stuff, and if there are good reasons to not implement some of the features of the previous version, that's completely understandable. However, it's difficult to try and contribute if I don't know if features are intentionally left out or if they are incomplete.

[CodeWithSwastik]

Most of the features from 1.5.4 will be implemented in 2.0.0 along with everything we couldn't implement before. (like Webviews, Progress etc). I'm looking to cover as much of the vscode-api as possible.

As for passing config data like version, I'm thinking about an ExtensionConfig class that can store all of that which can then be passed to Extension during init or run. This is because previously the init method had too many parameters. Do let me know if you have a better idea/implementation. You can work on this if you'd like.

There is also a Github Projects Board for Version 2.0 and you can pick something from the Todo if you'd like.

[Nicholas-Schaub]

Excellent. It seems like you have a lot of config files, and I think using some kind of configuration validation package might be a good idea here. I've use Pydantic in the past. Basically, just create a subclass of pydantic.BaseModel, define typed attributes, and then Pydantic does all necessary type checking. It even has some nice convenience functions, like dumping data to a formatted json file (which would allow you to generated the package.json in one line of code).

What would be nice is if we have a manifest json schema from vscode itself, because we could autogenerate the pydantic class, so we could always be up to date with the latest package manifest schema.

I did take a look at your board, and it was kind of sparse. Maybe I can throw a few ideas at you on here, and then if they sound like they are worth pursuing we can put them on there and I'm more than happy to contribute.

[CodeWithSwastik]

That's great, I was already looking to use pydantic. The manifest json for package.json is also a nice idea.

And yes the board is quite empty, I should really be more specific 🤣

I'm always open to ideas, would love to hear them.

[Nicholas-Schaub]

If you're okay with it, I can create a quick branch and either open a PR or share a link to what I was thinking about for pydantic.

Just to give you and idea of what my motivations are... I'm building a vscode extension for line-profiler. I want to be able to select functions to profile and scripts to run that will profile the code, then highlight the code to let you know what parts are the bottlenecks. I have working Python code that does this, but what I need my extension to do is actually run using the same active environment that the user is developing in. If I don't do that, then when I try to profile the code I get hung up on imports. I also need things to run from the local directory so that if someone is creating test code in their vscode work directory, it should be able to run that seemlessly as well. Then once the profile is done, I want to provide code highlighting to show the fast and slow parts of the code. I develop and oversee a lot of code, and having line profiling is super helpful.

So, anything I can do to help get your extension to the place where I can finish off the extension, I'm happy to help. I could just hard fork and implement all the necessary pieces, but I'm pretty dedicated to open source software. If there is a change I need to make to implement my extension and it doesn't fit with the repo, then I'll have to diverge my fork. But, I'll try to do all of it in a way that helps your repo. I like the way you're doing the rewrite so far, and it makes a lot of sense.

[CodeWithSwastik]

Sure you can create a PR or share the link.