How to maintain a low dependency version of a project?

Question

I am not as technically skilled as most people asking here. I use git to backup my own work to an online repository, but I rarely use it in collaboration, and don't know much more than the basic functions.

I have some code (think more like a gaggle of scripts, really) that I use to do some data processing. Frequently, other people (also somewhat technically skilled) want to see some of it. Unfortunately, the dependencies for running it include ROOT with Python 3 hooks (it installs by default with Python 2 hooks, and nobody is going to reinstall ROOT to run my code), and a number of other sizable libraries. My project is python 3 and so it probably won't be able to use most peoples ROOT installation.

In order to make things more accessible, I have a subset of modules that avoid any of more esoteric dependencies in another folder. However, I suspect there is a better way to maintain a low-dependency version than copy-pasting code.

I read this question: How to maintain different, customized versions of the same software for multiple clients and it looks like it might be the right direction. However, it said that the branches should contain minimal changes. I need a version of the project that contains only 1/3 of the files, with some minor changes in some files (removing imports). That seems significantly different to me. Is branches in a repository still the right way to handle this?

Answer 1

The answer you're referring to might be the accepted answer, but it is not the most upvoted answer. Quoting Alb's excellent answer (emphasis mine):

Don't do this with SCM branches. Make the common code a separate project that produces a library or project skeleton artifact. Each customer project is a separate project which then depends on the common one as a dependency.

The best option for you is to whip your "gaggle of scripts" into shape. Any functions, classes, etc. that are truly identical should be factored into independent modules that can be imported and integrated by the separate versions. You don't need to use a DI framework to get modular code.

You should structure the versions into separate folders with unique requirements.txt files for easy virtualenv creation. Then just keep both versions up to date in the same branch as you continue to develop.

You should also set up tests that validate your various versions' outputs on small examples and reported bugs to make sure that your future edits don't break existing functionality.

Answer 2

For what you described I would probably write a simple "build" script, which

• copies all the code you want to distribute into a separate folder (and nothing else)

• if necessary, makes the necessary modifications to the code in that copy, to remove the unneeded dependencies (like stripping some "import" lines).

You can write the script in Python as well, if you like.

So instead of manually copy-pasting the code you want to distribute, automate this task. This is not a "hack" or "trick": generating different variants of a software from a single source is a standard software engineering technique.

One can interpret as a "build process", with different build configurations produced by some preprocessor, which is very common when using compiled languages like C.

Of course, you should avoid having to modify too many places (if any) in the code by your script, since otherwise this could become error prone. Ideally, you have only a few files where you need to import the ROOT modules, and can leave them out during the copying process (but if that is not possible, just stripping some specific import lines is not really rocket science). You should also have some validation that the generated "partial" code base will run flawlessly, and that you did not forget to copy some important code files. Some automated test might be useful for this.