I think the perfect setup is: - foo is a pip-installable repo somewhere with its own CI - projectx is its own repo with its own CI - every projectx version is pinned to a specific foo version (by hash, or by pypi release)
You definitely have to do things in sequence still. You need to add functionality to foo before it can be used by projectx. But because you can pin to a hash, you can start using a foo version that's still in foo's pull-request queue in projectx pull requests. Most devs that work on projectx don't need to fork foo's code, pip pulls in the correct foo version automatically for them. Since you're using the main repo for both projects, the CI also remains simple. On 6 May 2014 14:57, Noon Silk <[email protected]> wrote: > On Tue, May 6, 2014 at 2:36 PM, Javier Candeira <[email protected]>wrote: > >> >> 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. >> > > Right. Okay, so I'm very happy if I'm not testing this common "foo" > library as part of testing my particular project using it (let's call it > Project X.) > > Well, maybe this solves everything. > > So we now claim that the ideal set up is: > - foo exists as a pip-installable source repo somewhere. > - foo has ci testing it for each pull req > - each programmer working on project x forks project x *and* foo > - foo is included as a "relative subrepo", say, of project x (i'm > ignoring this -e option by maybe claiming i'd like this to work for > non-python things too) > - now i can make changes to foo, commit them to my own repo. say someone > else is working on project_x with me; they do pull reqs to me; i am obliged > to accept pull reqs to both foo and project_x at the same time. > > But ... > - my dev_foo now needs it's own ci build? (how else will it be > auto-tested? or does this only happen on pull reqs up to the guy with the > ci build for it?) > > I guess there are still two problems. The ci builds for foo - who has > them? How do they get initiated? Say we're on github with travis. If I pull > req to the "main" repo; it will ci build for me. So do I rely on that? > Somehow this is now not completely continuous integration. It's some odd > version of it; notably, I might not see failures for a long time. The other > alternative - creating my own just for the fork - also seems odd. The other > problem is that I need to accept pull reqs to foo and project_x in some > order, otherwise the build breaks. > > -- > 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 > >
_______________________________________________ melbourne-pug mailing list [email protected] https://mail.python.org/mailman/listinfo/melbourne-pug
