separate github repos for language binding modules

[lbudai]

Proposed place for language binding modules

One of the purposes of having language bindings is to make contributors life easier.

We talked about this topic and decide that from contributors point of view a separate git repo for each language would be the way what we want to follow.

New github repos would be:

• balabit/syslog-ng-python-modules
• balabit/syslog-ng-java-modules
• balabit/syslog-ng-rust-modules

Plugin modules will be kept the original place (modules/python, modules/java, modules/rust, etc...).

Points

• Our reason for doing this that a {Python|Java|Rust} developer could install syslog-ng-core and syslog-ng-mod-{$LANGUAGE} from one of our OBS repos then cloning one of the language-modules and after that just writing the code in the selected language without care about C and any other languages.
• Other reason is re-usability of these modules between syslog-ng-releases (separate versioning, building and releasing, like incubator). The modules depend only on the language binding interface and not on the whole syslog-ng-core.

But before make it final we are interested in some feedbacks.

[juhaszviktor]

:+1:

[algernon]

:+1:

[deirf]

:+1:

[bazsi]

I like the idea in general, however I would include some modules to the syslog-ng release tarball as well. Basically the inclusion into the main proper would grant "officia" status, the ability to document them in our main documentation.

Having to fight for extension modules would be a hassle to users and the merger of production and non-production grade stuff would make the barrier to entry a bit higher. For instance, I don't care if a HTTP destination is in Python or Java or Rust or in C, I only care whether syslog-ng supports HTTP or not.

Bazsi

On Tue, Jul 7, 2015 at 12:24 PM, Zoltán FRIED notifications@github.com wrote:

[image: :+1:]

— Reply to this email directly or view it on GitHub https://github.com/balabit/syslog-ng/issues/548#issuecomment-119162312.

[lbudai]

Agree with the issues you pointed out. The way how source code and features are organized into repositories shouldn't be driven only by the programming language.

If someone wants to develop eg. a Java module, he/she just creates a github repo and keeps the code in that repo, no need for syslog-ng to be checked out (before compile, language binding module should be installed, but if it is available via a maven repo, it's not a problem). On the other hand, if someone wants to send a patch for one of the existing Java module, checkout is a must, but, well, it's not an issue in that case.

The key point for language binding modules could be that we make these language binding core modules available via a widely accepted distribution solution developed to the languge, if exists. I mean

• rust has crates.io
• python has pip
• java has maven repo

and we could publicate these core modules there own place. In that case, developing a new feature in these languages won't require syslog-ng source code.

Our goal is to support both

• developers
  • language binding core modules can be download easily with official developer tools
• and users
  • compile syslog-ng from source: official modules is a must

So the conclusion could be

• keep official module inside the main syslog-ng repo
• support developers with language binding core modules available in
  • pip,
  • maven repo, or
  • crates.io

[bazsi]

Sounds ok to me. On Jul 14, 2015 9:07 PM, "Budai Laszlo" notifications@github.com wrote:

Agree with the issues you pointed out. The way how source code and features are organized into repositories shouldn't be driven only by the programming language.

If someone wants to develop eg. a Java module, he/she just creates a github repo and keeps the code in that repo, no need for syslog-ng to be checked out (before compile, language binding module should be installed, but if it is available via a maven repo, it's not a problem). On the other hand, if someone wants to send a patch for one of the existing Java module, checkout is a must, but, well, it's not an issue in that case.

The key point for language binding modules could be that we make these language binding core modules available via a widely accepted distribution solution developed to the languge, if exists. I mean

• rust has crates.io
• python has pip
• java has maven repo

and we could publicate these core modules there own place. In that case, developing a new feature in these languages won't require syslog-ng source code.

Our goal is to support both

• developers
  • language binding core modules can be download easily with official developer tools
  • and users
  • compile syslog-ng from source: official modules is a must

So the conclusion could be

• keep official module inside the main syslog-ng repo
• support developers with language binding core modules available in
  • pip,
  • maven repo, or
  • crates.io

— Reply to this email directly or view it on GitHub https://github.com/balabit/syslog-ng/issues/548#issuecomment-121344419.

[justcallmegreg]

:+1: