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

[Noon Silk]

There's another problem with this maintain-a-fork business.

How does it work for random people wishing to contribute? They are forced
to have k forks for all the libraries I've decided to include in this
manner. If they fork the main repo, I need to kind of "break" their fork
until they also fork the relevant libraries. Maybe this is a feature, but
I'm not sure I've seen any open source projects that work this way ....



On Tue, May 6, 2014 at 1:58 PM, Noon Silk <noonslists at gmail.com> wrote:

> 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."
>



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