Ok, that would work. Doing it how you explained would probably suppose that we have to at least update the packages that make the tests fail in dependencies.tsv but we should eventually update all packages that use gocheck. This needs to happen at some point anyway because otherwise we can't bring updates from gocheck into anything really, if it's maintained on github now and we aren't using that. I'd rather see it happening sooner rather than later, it's just going to get harder if it also gets up to a point where it breaks functionality as well.
We might be able to add the changes so only that commit gets pulled, but that depends on how godeps is implemented and I'm not completely sure if that would work. Bogdan ________________________________ From: John Meinel [[email protected]] Sent: Friday, September 05, 2014 5:29 AM To: Bogdan Teleaga Cc: [email protected] Subject: RE: Changing gocheck fetch url So it isnt the name change per say, even if they were the same name you'd get type errors due to a different import path. It doesn't matter if they all land at the same time. All of the dependencies can be updated and the test suites should pass in all of their trunks. In juju-core we won't have changes dependencies.tsv yet so when you use godeps to bring in the right version, the tests will still pass on juju-core trunk. And when the dependencies are ready we update the world with a updated dependencies.tsv in the same commit that changes our go check library. Now the question remains... changing an import like this is very incompatible for everyone else but only in your test suite. Does that mean we should be bumping the import version for all packages? John =:-> On Sep 4, 2014 9:29 PM, "Bogdan Teleaga" <[email protected]<mailto:[email protected]>> wrote: The main problem with this approach is the fact that there are still dependencies between the packages that are not fulfilled. Mainly because the package name has been changed from gocheck to check, I get lots of type errors when updating dependencies by themselves. What works so far is replacing everything under juju + the gopkg.in/juju/charm.v3<http://gopkg.in/juju/charm.v3> package which also causes some trouble. As long as they're updated at the same time, the tests continue to run perfectly. Any ideas on how we might achieve this? I think simply putting up PR's on each repo isn't feasible since they won't be merged at the same time. Bogdan ________________________________ From: John Meinel [[email protected]<mailto:[email protected]>] Sent: Thursday, September 04, 2014 8:02 AM To: Bogdan Teleaga Cc: [email protected]<mailto:[email protected]> Subject: Re: Changing gocheck fetch url I would migrate things over one at a time, as there shouldn't be dependencies between them (test suites are run in a separate process for every package). There is likely to be some "testing" packages that are used in multiple packages, but that should all be in the juju-core layer. There might be some test harnesses from other dependencies, but we have proper lock-step dependency management already. So my suggestion is to put up proposals for the dependencies, land them, then update juju-core and dependencies.tsv at the same time, and everything should go smoothly. John =:-> On Wed, Sep 3, 2014 at 7:05 PM, Bogdan Teleaga <[email protected]<mailto:[email protected]>> wrote: Hey, It seems that gocheck is still updated from https://launchpad.net/gocheck. However, as you can see if you check the page the project has moved to github(https://github.com/go-check/check) and this results in us not having the latest updates. So far I've tried doing a global sed in a backup go/src directory and everything seems to be working fine test-wise. However we need to commit everything in the respective repositories for godeps to work correctly. Is there any particular way we should go about doing this? I can get patches ready for every particular repo if needed. Bogdan -- Juju-dev mailing list [email protected]<mailto:[email protected]> Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
-- Juju-dev mailing list [email protected] Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
