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

[Noon Silk]

> Sounds like you probably have two libraries, a public and private
> one. I would fork the latter (private) from the former (public) and
> put it on a private online repository. Then you can install the private
> version using pip's git+ssh functionality.
>
> Any changes you make to private library could be potentially pushed
> back upstream to the public one.

I've maybe not been completely clear. I just want to know the Best Way to
maintain a common repository inside another set of repositories that
reference it. It doesn't really make a difference if they are public or
private (assume they are both public, in the case I'm thinking of doing
this, they are.)

I'm not entirely sure of the best way to easily share common code with my
own code in python; subrepos, symlinks, completely external lib, that
support, in the nicest way possible, testing of changes, commiting of
changes as functional units, and minimal overhead in actual work so I can
do actual programming.




On Tue, May 6, 2014 at 10:54 AM, Peter Davis <peter.davis8 at gmail.com> wrote:

> Hi,
>
> Sounds like you probably have two libraries, a public and private one. I
> would fork the latter (private) from the former (public) and put it on a
> private online repository. Then you can install the private version using
> pip's git+ssh functionality.
>
> Any changes you make to private library could be potentially pushed back
> upstream to the public one.
>
> Peter
>
> On 6 May 2014, at 10:45 am, Noon Silk <noonslists at gmail.com> wrote:
>
> 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."
> _______________________________________________
> melbourne-pug mailing list
> melbourne-pug at python.org
> https://mail.python.org/mailman/listinfo/melbourne-pug
>
>
>
> _______________________________________________
> melbourne-pug mailing list
> melbourne-pug at python.org
> https://mail.python.org/mailman/listinfo/melbourne-pug
>
>


-- 
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/b1229577/attachment.html>