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

[Javier Candeira]

What I do:

pip has an option, -e, which installs an "editable" version of a library

and you can pip install from a repository, like so:

pip -e git+https://github.com/candeira/ansible.git@a002a249731ca7c7dd35d0d4f79108b632fde2dd#egg=ansible-dev

Now my development virtualenv is running this particular library from
its src/ansible/ directory, an editable git repo which I can modify,
checkout branches and, in this case, since Ansible is not my project,
make pull requests with bugfixes and features. If it were mine, I
could publish the appropriate branch to git master and to the cheese
shop.

The workflow is still not set in stone, but works quite well for me.

J

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
>