[melbourne-pug] The One True way to structure repositories for common code re-use

Noon Silk noonslists at gmail.com
Tue May 6 02:45:36 CEST 2014


Hello,

  Suppose you are writing some code. Suppose one day, you decide "hey, this
bit of code is sufficiently common, I'll make it into an independent
library!", so you do that, you publish it on github and bask in the
green-ness of your travis build.

  Now suppose you want to use this common library in your own "main" app
somehow. You have a few options for including it:

  1) Local copy in your repo either as:
    - Subrepo pointing at source,
    - Subrepo pointing at your own fork (note: in the above case you might
want to modify the public library in some way that is not compatible with
the public goals, but more of a specific thing for your own internal stuff.)

  2) Local copy as symlink to a clone or fork as above

  3) Completely independent thing that you pip install

 What option do you take? (I've probably missed other better ideas.) I have
some feelings about this, but I'm not entirely sure which way is the best
way yet, and am interested in opinions, and maybe more interested in *what
you actually do*.

  Suppose that the common library is changing "somewhat often"; maybe once
a month or so. Let's suppose you'd prefer to move functionality into that
library, but you can forsee needing to modify it for your own needs (well,
if so, does this just flat-out eliminate option 3?).

  Note, I suppose, in the options where you might accidentally modify it
(when you have a local copy) you probably need to be running the tests.

-- 
Noon Silk

Fancy a quantum lunch? https://sites.google.com/site/quantumlunch/

"Every morning when I wake up, I experience an exquisite joy -- the joy
of being this signature."
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/melbourne-pug/attachments/20140506/c837289c/attachment.html>


More information about the melbourne-pug mailing list