Re: how to update dependencies.tsv
On 30 October 2014 14:34, Eric Snow eric.s...@canonical.com wrote: On Thu, Oct 30, 2014 at 4:40 AM, roger peppe roger.pe...@canonical.com wrote: It's a pity then that if you go get a package, origin is the repo you've branched from. There is always one of those, but you don't necessary have a fork of the repo yourself. Why wouldn't you want go get to fetch from your clone by default? What Andrew said. Also, the only information that go get has when a repository doesn't exist locally is the home of that repository. So when go get gets a new package, the only place that origin can point to is that repository's home. When starting work on a package, the first thing I will do is invariably go get that package, which will fetch all new dependencies too. For the majority of those dependencies, I won't already have forked them on github. If I come to start work on one of those dependencies, it will already have an origin remote pointing to the source of the repo. So it's much easier IMHO just to go with the flow and keep origin always meaning the same thing, whether you've forked the repo or not. FWIW I never use git clone to copy Go package repositories locally. -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
New regression: set-env no longer accepts empty values
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I have discovered a regression in juju set-env. I have filed a bug accordingly: https://bugs.launchpad.net/juju-core/+bug/1388073 A recent change to juju broke set-env, so that it no longer accepts empty values. In old versions this worked: juju --show-log set-env -e kvm-upgrade-trusty-amd64 tools-metadata-url= In new versions, it gives: error: expected key=value, got tools-metadata-url= Revision f81cc435 is the first version that our tests show exhibits this bug. We also know that 289da217 did not exhibit this bug. This is a regression because - - It breaks commandline compatibility with other juju releases - - It breaks CI -BEGIN PGP SIGNATURE- Version: GnuPG v1 iQEcBAEBAgAGBQJUU4Z4AAoJEK84cMOcf+9hXB4H/2gonXpLZnEvwhQRegF4khM1 s8r6VL7siQO6N2NeVWqH0tNzCHT8F2yOWN1bPJuiql0QsOtCe/ejqTDDOiyE5qjY 6SyZ4Gp9MPLxED/dplUsYeaIRSa6EJOmLPNG6KP+IQmT8hPE0bv5ZACk1qDDXPGh JZW2Wr4Xr1L/13xzY8UdUc2J6hZ3lsTkwCLLjsvSIJ0SjIGn9lVUR29PNRu/1GxT ETdpdTeYy1blqT+B/O5lLJS7LGdG5+Xlc4xKjOv3gvXPjMHxw0mU8mSleAOWEohY 5y/HTOGZgYDCSTVLaZIAaiTQIaZEsqikZnivtXvNh8pSW7nl/zUxERsY111JQHg= =umDh -END PGP SIGNATURE- -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: deprecating the juju-backup (and juju-restore) CLI plugin
On Fri, Oct 31, 2014 at 8:35 AM, Curtis Hovey-Canonical cur...@canonical.com wrote: On Thu, Oct 30, 2014 at 2:10 PM, Eric Snow eric.s...@canonical.com wrote: What would be the best approach for deprecating the old backup plugin? I was going to simply gut it (it's a bash script) and stick in a deprecation warning message and a call to juju backups create --download. However, jam rightly pointed out to me that this may be a sticky situation (as described above). I'd really like to find a way to eliminate the old backup implementation. Thoughts? Look before you leap. Call juju status and check that the version is 1.21.+ and use new command, else old command. Good idea. We expect new clients to manage old state-servers during transitions. The transition my be long if the enterprise is not upgrading their envs. I think we are stuck with the old implementation for as long as we support trusty. Yeah, that's what I figured but hoped wasn't the case. Users do not know that backup is a bash script... juju backup is the command, so we can write an alternate plugin that checks the state-server version, then either calls to new command or the old script which is renamed, If we rename/change juju-backup.bash, we need a simultaneous packaging change. Since it is transparent to users and otherwise mostly irrelevant, I'll leave the filename alone and add the conditional operation to the existing script. Am I okay with adding a deprecation warning message (to stderr) that instructs juju backup users to use juju backups create instead? I'm not sure what precedent there is for doing so with our CLI. -eric -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
Re: how to update dependencies.tsv
FWIW, I always branch off upstream/master. I don't have master synced to my repo, because it just seems like an extra step. Why not go straight to the source? On Oct 31, 2014 11:48 AM, Eric Snow eric.s...@canonical.com wrote: On Fri, Oct 31, 2014 at 2:11 AM, roger peppe roger.pe...@canonical.com wrote: On 30 October 2014 14:34, Eric Snow eric.s...@canonical.com wrote: On Thu, Oct 30, 2014 at 4:40 AM, roger peppe roger.pe...@canonical.com wrote: It's a pity then that if you go get a package, origin is the repo you've branched from. There is always one of those, but you don't necessary have a fork of the repo yourself. Why wouldn't you want go get to fetch from your clone by default? What Andrew said. Also, the only information that go get has when a repository doesn't exist locally is the home of that repository. So when go get gets a new package, the only place that origin can point to is that repository's home. Right. I'm not suggesting that go get (or godeps) change the remotes for a repo that didn't already have a local clone, nor even for any existing local clones. In fact, I'm saying that the current behavior of go get is just fine. It shouldn't need to worry about any other remotes than origin, regardless of if the local clone already existed. Neither should it worry about where origin is pointing, nor about syncing origin with upstream. If someone has pointed origin to point to their own remote [1] clone (which is what the juju CONTRIBUTING doc suggests), then they are responsible for keeping that synced up with upstream. If they don't and godeps has issues because it can't find the revision it wants, that isn't the fault of godeps or go get. I believe the request from earlier (Tim?) is that godeps help out in that case. [2][3] However, that should not require that go get have any awareness of remotes. When starting work on a package, the first thing I will do is invariably go get that package, which will fetch all new dependencies too. For the majority of those dependencies, I won't already have forked them on github. If I come to start work on one of those dependencies, it will already have an origin remote pointing to the source of the repo. So it's much easier IMHO just to go with the flow and keep origin always meaning the same thing, whether you've forked the repo or not. Right. That is fine and should not change, nor need to. It's the case where you did change your remotes that godeps *could* be more helpful, regardless of whether or not it's worth doing. -eric [1] I suppose you could also point origin to another repo elsewhere on your local filesystem. [2] I was going to pull this conversation into a feature request on the godeps issue tracker, since it is basically a distraction from the original thread topic. However, I didn't find any such tracker. The launchpad project does not seem to have one enabled and there is no github repo, [3] Regarding the feature request, here's a possible solution. If the revision for a repo is not found in origin (after running go get), look for it in upstream (if that remote exists). If upstream exists but the revision isn't there, give a warning that upstream may be out of date. I suppose godeps could also try fetching from upstream first (without pushing any changes to upstream). -- Juju-dev mailing list Juju-dev@lists.ubuntu.com Modify settings or unsubscribe at: https://lists.ubuntu.com/mailman/listinfo/juju-dev
