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 <[email protected]> wrote: > 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." > -- 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
