Discussion: How do we include “small bits and pieces” (e.g. tinyexpr.c/h) ensuring a clear upgrade path

[willend]

The dilemma

For small inclusions of functionality (i.e. ~ single file) “from elsewhere” it is tempting to just dump a local file in the McCode repo.

While this seems easy here and now, it may pose challenges later on when the “upstream project / resource” make a new release / fix a bug etc., especially since updating the included code is no longer automated. Any local edits complicates this manual approach even further.

Depending on licensing situation of the upstream code wrt. McCode (GPL 3) this approach may also be problematic.

Example case

A recent example is the inclusion of the union process Inhomogenous_incoherent_process that relies on functionality from tinyexpr, in the form of including the flat files tinyexpr.c and tinyexpr.h into mcstas-comps/share. The files have since been modified locally from their upstream counterparts.

My first suggestion for a better way

I think we ought to rather

1. fork the upstream code (at best to our own mccode-dev org
2. make local modifications there
3. ‘release’ on local modification - with a package name of e.g. mccode-tinyexpr
4. Pulling in upstream updates by PR / patch / merge

• Or as an absolute minimum engage with the author of upstream to ensure he thinks we are being nice or if he has a better suggestion?

[Lomholy]

This seems like a good idea, such that we don't "silo" the code we grab from other places (And for the licensing reasons!).

A possible alternative
One thing I was contemplating on the train this morning, is whether we should prioritize expanding upon current capabilities in the Mccode software to get these small functionalities. We (@willend and I) discussed that the Mccode parser does have something similar to tiny expressions, that might be able to fill the same niche, but currently we may "just" have duplicated this bit of code.

While there is nothing wrong per say with this duplication, we might be obfuscating the capabilities of our software for new users and developers, by having multiple sections of code that does basically the same thing, but a little different.

But I think that this may be a per situation evaluation by the maintaners that should be perfomed (And I find it reasonable to ask me to expand upon the Mccode parser to include this kind of math interpretation).