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

[Noon Silk]

On Tue, May 6, 2014 at 1:46 PM, Javier Candeira <javier at candeira.com> wrote:

> Resending to the list. Noon: note I've added some clarifications over
> what I sent you by mistake.
>
> On Tue, May 6, 2014 at 1:31 PM, Noon Silk <noonslists at gmail.com> wrote:
> > 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?
>
> No, you aren't. It's an external library. If you require, say, Kenneth
> Reitz's Requests and install it in your virtualenv, you don't run its
> tests every time you commit something to your project. Here it's the
> same, except that the library is not Reitz's but yours, and it's still
> under some (mild) development.
>
> You only need to run the tests for your library when you modify your
> library.
>

Indeed! Maybe you address it below, but if I am not unit testing it, but
perhaps making changes, (you said I'm installing it in "edit" mode), then I
must run the tests associated to it!

How do I do this if I don't know when changes have been made to it? (Maybe
another dev changed it, the travis-ci should notice ...)



> > 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?
>
> Pip can point to a particular commit, and in my example it does. So
> you can write on your repo's requirement.txt that commit that does a
> fix on your own repo. Once it's accepted in the mainline repo, you can
> modify your requirements.txt to point to the merge commit on the
> mailine repo.
>
> > Am I understanding right
> > in that they can't get the changes, because the changes will be contained
>
> The changes are contained in a git commit, so you can put that in your
> requirements.txt and ask everyone to update (or have the update in a
> git hook).
>

But how do they get the commit? To which repo did it go? Ah, I see, in your
scenario here the commit is going to your own fork of the main project.
Alright. I guess in order to make this work each developer needs to have a
fork of the common repo, but if you do this, it avoids the situation I
describe below.


> 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
>
> If it's not your library, yes. If you are the main author, you work
> from a checkout of development tip, or your feature tip, or whatever.
> And your repo can be public or private. It's your project.
>
> > 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 libraryre  as a single set, they must be a
> separate]
>
> I don't understand the difference between the common library and the
> internal one. Git is truly distributed. You can keep a private branch
> whose tracking remote is your private repo, and a main branch whose
> tracking remote is the public repo. I do that with my Ansible
> development: my branches track my own repo, so I can git push by
> default, but devel tracks the devel branch on upstream ansible repo,
> so I can git pull and see what's been done.
>
> The people in your team install from your requirements.txt, and the
> pip -e line on that one should have a release tag or a commit hash,
> not a branch name.
>
> J
>

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