>> You only need to run the tests for your library when you modify your >> library. > 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 ...)
Yes, it's now a separate library. It may be in development, but it's tested separately. >> > 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 Your application repo includes a requirements.txt for your virtualenv, which is updated to point to the new commit for the library. You can set git hooks to make sure that the virtualenv is always updated to what the file says. > 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. Each developer has a local checkout of a branch. Whether that branch is a fork is only a matter of perspective, whether there is a "master" that's external to the development team. J _______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
