On Tue, May 6, 2014 at 1:46 PM, Javier Candeira <[email protected]> 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 <[email protected]> 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."
_______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
