3

This might be a novice question, so please excuse. We have a small python development team and our repo is organized as indicated below. We have a custom library that is shared across multiple scripts (wrappers) and then libraries specific to each wrapper. The below structure is maintained under Git. This has worked so far for development. Now we would like to release the wrappers, but individually. As in, we need to release wrapper1 targeting a separate audience (different timelines and needs) and at a later time wrapper2. Both need to contain the shared_library and only their specific library. What is the best way to do this? 

repo/:
    wrapper1.py
    wrapper2.py
    shared_library/:
        module1.py
        module2.py
    wrapper1_specific_lib/:
        wrapper1_module1.py
        wrapper1_module2.py
    wrapper2_specific_lib/:
        wrapper2_module1.py
        wrapper2_module2.py

We have considered the following solutions:

  1. Re-org as three separate repos: wrapper1, wrapper2 and shared_library and release separately.

  2. Have two separate repos for wrapper1 and wrapper2 and periodically sync the shared library (!!?!!)

  3. Leave it like this but explore if it is possible to use Git in some way to release selected files, folders specific to each wrapper.

Seeking you help on python code-organization for better release management using Git. Thanks in advance!!

sk-bioinfo
  • 37
  • 5
  • 1
    How are you doing releases now? Are you going to have them pull the library from github? – erik258 Dec 12 '17 at 00:59
  • 1
    If your organization can host a pypi mirror, you could distribute each wrapper as a package allowing endusers to install via `pip`. – Jordan Bonitatis Dec 12 '17 at 04:08
  • @Dan We haven't released yet. The plan is to pull from GitHub. Thanks – sk-bioinfo Dec 12 '17 at 21:51
  • @Jordan: That is certainly one way, but I was wondering if this could be done leveraging Git and python code structure. THanks. – sk-bioinfo Dec 12 '17 at 21:52
  • 1
    Another approach you may consider would be manage via branches. Each lib/module could have their own `dev`/`staging`/`release` branches and when that particular branch is ready for the broad release, you can cut it into `master` – Jordan Bonitatis Dec 12 '17 at 22:44
  • 1
    If you want to deploy from git, I'd recommend separate repos. It's not really much effort to pull things apart once, but it's always easier to combine than extract at deploy time. – erik258 Dec 13 '17 at 00:12
  • 1
    You can set up all three as separate repos and have the shared lib as a [submodule](https://git-scm.com/docs/git-submodule). – R Nar Dec 13 '17 at 19:32

1 Answers1

1

You have 3 products, each with its own release timeline. Wrapper1 users are not interested in seeing wrapper2 code, and vice versa. Breaking out into 3 repos would be the simplest approach.

Do take care to package automated unit tests into the shared_library repo. Both of the dependent apps should be able to successfully run their own tests plus the shared tests. This will become important as the released apps submit new feature requests and try to pull the shared_library in different directions.

J_H
  • 17,926
  • 4
  • 24
  • 44