External Generator Modules in Glad 2

[Dav1dde]

I've had some issues in the past (glad 1) with generators I can't personally support going outdated or me just not being able to help with, luckily the original authors were still around and really helpful. That's why I for glad2 built an extension system which should allow external generators to work basically as flawless as if they were merged in tree (basically just pip install glad-{extension} and it works out of the box).

That allows independent iteration on the code and hopefully makes the maintainership more explicit.

The plan is to still provide these externally maintained generators on the website.

What do you think about this, do you see any drawbacks here, would you rather have your code merged in tree?

[AarnoldGad]

I am not an expert, and this is the first time I contribute to a project like this after glfw (PR pending), but I will try to open the discussion, and probably mention things that are not so interesting. So please, don't hesitate to correct me or ask questions.

Clearly, using the extension system and decoupling community-maintained generators from the main branch means more explicit maintainership, as you said, and that the main code is not constrained by broken or outdated generators and is therefore more stable and easier to maintain.

One of the first thing I am thinking is that this generates additional dependencies when pip installing glad. I don't think this is much of a concern, but you know, one should always be careful when using/creating too many dependencies.
Also, the webservice does everything as far as the user is concerned.
I also think it is possible to set up "extras"/optional dependencies in the setup.py, although pip does not prompt the user to install these.

I am also wondering if an extension/external generator can be detected as outdated for a specific version of glad. As I have not dealt with outdated generators, I don't know exactly how this would show up.

As external generators would then be in their own repos, I think it would be good to have a list somewhere (e.g in the README file) on the glad2 repo to reference them and their maintainers. But perhaps this goes without saying.

Personally, I don't see any particular drawbacks with this method, quite the contrary. However, maybe this means a tiny bit more work for contributors, having to create their own pip package and setup.py and make sure it works with the main glad2 package, I suppose having it as a dependency? I don't know exactly how one would go about this, as I have never done it, but I doubt it would be so hard. Maybe it would be worth having a short entry in the wiki showcasing a basic setup for an external generator.

[Dav1dde]

I also think it is possible to set up "extras"/optional dependencies in the setup.py, although pip does not prompt the user to install these.

I think we can set this up through extras/optional dependencies glad[fortran] for example.

I am also wondering if an extension/external generator can be detected as outdated for a specific version of glad. As I have not dealt with outdated generators, I don't know exactly how this would show up.

That may be a bit of an issue but I don't plan on breaking the API which hopefully is good enough.

As external generators would then be in their own repos, I think it would be good to have a list somewhere (e.g in the README file) on the glad2 repo to reference them and their maintainers. But perhaps this goes without saying.

Yes!

maybe this means a tiny bit more work for contributors, having to create their own pip package and setup.py and make sure it works with the main glad2 package

Ideally they'd publish it as a pypi package, but pip can install from git.

Maybe it would be worth having a short entry in the wiki showcasing a basic setup for an external generator.

Agreed, the docs are very slim :(