Core and external modules

[Jarod42]

Mostly talking about generator/action modules.
I wonder what would be needed to:

• embed external modules

For release, we have to "fetch" (curl, git, git submodules..) external approved modules and embed them.

Not sure how doc might support that. (BTW, that might help to organize help

• make Core modules external

then core modules can be externalized

[samsinsane]

I wonder what would be needed to:

• embed external modules

Let me answer your question with questions:

• Who is maintaining these external modules?
• When an external module breaks, who fixes it?
• When an external module is abandoned, do we remove it from the list of embedded external modules?
  • If not, why not? Who is expected to maintain it now?
  • What if it's really popular?
• Is premake-core allowed to break a public API? flags for example?
  • What about an internal API? table.sort for example?

• make Core modules external

then core modules can be externalized

This used to be how Premake was setup, it was awful for development. As far as I'm aware, there is no interest in going back to that setup - I am certainly very much against it, I had multiple PRs blocked for months due to issues with modules.

[Jarod42]

Let me answer your question with questions:

Who is maintaining these external modules?

As now... (so mostly people not from premake-core team).

When an external module breaks, who fixes it?

As now, people working on those modules.

When an external module is abandoned, do we remove it from the list of embedded external modules?
If not, why not?

Policy to choose which modules is embed is up to premake-core team.
I would say passing integration tests would be a pre-require.
As long as the module is working, no need to remove it, but up to you.

Who is expected to maintain it now?

Nobody.

What if it's really popular?

If it is popular, I would expect someone (not from premake-core) to maintain that module possibly as fork, so not abandoned ;-)

Is premake-core allowed to break a public API? flags for example?
What about an internal API? table.sort for example?

As currently.

then core modules can be externalized

This used to be how Premake was setup, it was awful for development. As far as I'm aware, there is no interest in going back to that setup - I am certainly very much against it, I had multiple PRs blocked for months due to issues with modules.

I though it was a wanted move.
External modules tend to be out of sync with core more than internal ones.

(From premake4) you remove/externalize Code::Blocks. keep Codelite, add xcode4...

Ninja, which is a popular alternative to Makefile is an external module.

With embed, we just have premake5 executable :-)
Having a (custom) premake executable with selected modules would be fine IMO.

[samsinsane]

I though it was a wanted move.

This is news to me.

External modules tend to be out of sync with core more than internal ones.

Exactly. It's not because they're not bundled into the Premake binary, it's because they're not in the premake-core repo. A submodule doesn't fix this, we already know this. It just creates hurdles to merge PRs, or leaves us unable to release a new build because a submodule doesn't work.

Ninja, which is a popular alternative to Makefile is an external module.

It's been several years since it was suggested that we merge that module into core. The unit tests still seem to be written in only Python and you seem to be the only one maintaining it now. No matter how popular Ninja is, if nobody is going to do the work, it can't be merged in.

---

Ultimately, whatever actions are shipped in the Premake binary will be expected to be supported and working going forward. This repo will receive all the bug reports, and it will be the core maintainers that will be responsible for informing the module maintainers (if any actually exist). All I'm seeing here is a request for the core maintainers to take on even more responsibilities despite our very limited time.

[Jarod42]

Ok, that clarify things.