Comment 11 for bug 707075

On 29 January 2011 11:28, Max Bowsher <email address hidden> wrote:
> I see what's breaking here. In 1.5.5, launchpadlib redefined the meaning
> of a service_root URI from including the trailing version component to
> excluding that. Yuck, that's a nasty compatibility break. At this point,
> the service root constants in bzr still use the old launchpadlib <=
> 1.5.4 form with a trailing /beta/. *However*, bzr 2.3 doesn't use a
> hardcoded string for the production service root any more, but uses the
> imported LPNET_SERVICE_ROOT, which means if you're running bzr >= 2.3,
> this bug is masked.

It sounds like we should file a bug against launchpadlib about that?

> So, I think I've figured out how to fix this. We do all of our service
> roots via the *_SERVICE_ROOT constants imported from launchpadlib. For
> any service roots not present as constants, we construct them by
> changing the hostname of the STAGING_SERVICE_ROOT value, but we retain
> any path component present there. That way we always match the
> expectations of the launchpadlib we are actually running against.

I suppose to support our existing behavior we have to do that. Going
forward, perhaps we should just remove this. Using anything but the
default service root is a developer-oriented feature, and it may
simpler for them just to take the lp ws url from an environment
variable.

--
Martin