5

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?

  • Did I get this right: the part of the project you want to offer to others is Python 3, but does not really depend on ROOT / could work without those imports? – Doc Brown Nov 14 '18 at 15:34
  • @DocBrown yes that is right. Everything in the project is python 3. Some parts of the project depend on ROOT. The part of the project I want to share does not depend on ROOT. – Clumsy cat Nov 14 '18 at 17:13
10

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.

  • I don't have python 2 support, there is a simulation library called ROOT that by default has python 2 support (and not 3). I don't work on ROOT, but parts of my project use it. Sorry for the confusion. – Clumsy cat Nov 14 '18 at 9:03
  • 1
    I understood from that statement that some of your users were running Python 2. The points about factoring your code into modules and importing them into minimally redundant versions that integrate (subsets of) them still stands. – Alex Reinking Nov 14 '18 at 9:08
  • 1
    @Clumsycat - I added a bit more detail and removed the info about Python 2/3 cross compatibility in light of your edits to the question. – Alex Reinking Nov 14 '18 at 9:16
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.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.