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

[Noon Silk]

> The above posted workflow gives you the tools to fulfill the
> requirements of 3a and 3b.

Yes interesting.

Okay, so but then as part of the ci-build for this local internal project,
you are constantly testing the maybe-not-ever-changed version of the thing
you pip-installed?

Suppose also you make changes to this library, and they aren't accepted
into the master repo by the maintainer. How do you now share the changes
you made with the other developers of your internal thing? Am I
understanding right in that they can't get the changes, because the changes
will be contained only in a pending pull request? (i.e. for this to work,
you'd need to work from a fork of the common library, and basically always
merge in pull requests  to the fork. This seems somehow a bit broken to me,
I think [you can't submit a set of changes that contain changes both in the
common library and the internal library as a single set, they must be
a separate]  ...)



On Tue, May 6, 2014 at 11:38 AM, Javier Candeira <javier at candeira.com>wrote:

> What I meant to say is that 3) is, to me, the right answer.
>
> a) If it's a general library, it belongs in your installed libraries,
> not in your application's source tree.
> b) But since it's your library to maintain, you can still keep it
> around as an editable, live piece of code.
>
> The above posted workflow gives you the tools to fulfill the
> requirements of 3a and 3b.
>
> J
>
> On Tue, May 6, 2014 at 11:16 AM, Javier Candeira <javier at candeira.com>
> wrote:
> > 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
> >>
> _______________________________________________
> 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/15b907f6/attachment-0001.html>