please make launchpad.load() work again

[Brian Murray]

Binary package hint: python-launchpadlib

With the latest version of python-launchpadlib I am unable to use launchpad.load() at all. I can work around the issue by changing the DEFAULT_VERSION in launchpad.py from "1.0" to "beta" but that's not a good solution.

launchpad.load('https://api.edge.launchpad.net/') results in an OOPs and a 404

launchpad.load('https://api.edge.launchpad.net/beta/') results in AttributeError: 'Entry' object has no attribute 'self_link'

launchpad.load('https://api.edge.launchpad.net/1.0/') gets me
NotImplementedError: Can't look up definition in another url (https://api.edge.launchpad.net/1.0/#service-root)

launchpad.load(EDGE_SERVICE_ROOT) results in another OOPs and a 404

I've poked around quite a bit and haven't gotten anywhere. Additionally, this wasn't mentioned in https://lists.ubuntu.com/archives/ubuntu-devel/2010-March/030539.html which is irritating.

ProblemType: Bug
DistroRelease: Ubuntu 10.04
Package: python-launchpadlib 1.6.0-0ubuntu1
ProcVersionSignature: Ubuntu 2.6.32-19.28-generic 2.6.32.10+drm33.1
Uname: Linux 2.6.32-19-generic x86_64
Architecture: amd64
CheckboxSubmission: fee5e196cb921cbd36888f428b38b488
CheckboxSystem: 2a6f54df59af338184485e85cbcf0d32
Date: Tue Apr 13 15:27:22 2010
PackageArchitecture: all
ProcEnviron:
 PATH=(custom, user)
 LANG=en_US.UTF-8
 SHELL=/bin/zsh
SourcePackage: python-launchpadlib

[James Westby (james-w)]

On Tue, 13 Apr 2010 22:36:38 -0000, Brian Murray <email address hidden> wrote:
> Public bug reported:
>
> Binary package hint: python-launchpadlib
>
> With the latest version of python-launchpadlib I am unable to use
> launchpad.load() at all. I can work around the issue by changing the
> DEFAULT_VERSION in launchpad.py from "1.0" to "beta" but that's not a
> good solution.
>
> launchpad.load('https://api.edge.launchpad.net/') results in an OOPs and
> a 404
>
> launchpad.load('https://api.edge.launchpad.net/beta/') results in
> AttributeError: 'Entry' object has no attribute 'self_link'
>
> launchpad.load('https://api.edge.launchpad.net/1.0/') gets me
> NotImplementedError: Can't look up definition in another url (https://api.edge.launchpad.net/1.0/#service-root)
>
> launchpad.load(EDGE_SERVICE_ROOT) results in another OOPs and a 404

None of these would have worked before would they? They don't reference
any objects.

You should be able to do

  launchpad.load('https://api.edge.launchpad.net/1.0/ubuntu')

where 1.0 matches the version of the webservice you are using.

Note that doing this is fragile, and launchpad.load should support
relative URIs so that it isn't.

In the meantime you can do

  launchpad.load(str(launchpad._root_uri) + ubuntu)

Thanks,

James

[Brian Murray (brian-murray)]

In karmic EDGE_SERVICE_ROOT = 'https://api.edge.launchpad.net/beta/'
In lucid EDGE_SERVICE_ROOT = 'https://api.edge.launchpad.net'
Subsequently, if you were to try to use launchpad.load(EDGE_SERVICE_ROOT + 'ubuntu') it'd fail. I still see this as a regression. While there was a merge done to the ubuntu-qa-tools branch that resolved this for those scripts using launchpad.load() I think the change was poorly messaged.

[Leonard Richardson (leonardr)]

Old scripts tend to use launchpad.EDGE_SERVICE_ROOT and launchpad.STAGING_SERVICE_ROOT. These constants are deprecated. Currently they are imported into launchpadlib.launchpad from launchpadlib.uris.

from launchpad.uris import EDGE_SERVICE_ROOT, STAGING_SERVICE_ROOT

Since the whole point of maintaining these constants is to stop old scripts from breaking, we could tack on a hard-coded version number ('1.0', _not_ 'beta').

from launchpad.uris import EDGE_SERVICE_ROOT as _EDGE, STAGING_SERVICE_ROOT as _STAGING
EDGE_SERVICE_ROOT = _EDGE + "1.0"
STAGING_SERVICE_ROOT = _STAGING + "1.0"

This doesn't change the basic facts that 1) load() should be made to support relative URIs and 2) scripts should not be using these constants.

[Gary Poster (gary)]

Because the affected ubuntu scripts are fixed, and we're trying to deprecate this usage anyway, I'm triaging this as low. If I don't get any complaints after a while, I'll change it to a "Won't Fix". On the other hand, if I get more reports of problems, I'll raise the priority.

We will try to consider, and better serve, older launchpadlib scripts in our messages in the future.

Moreover, we want to make it possible to test code using launchpadlib more easily, and in a way that is more tightly integrated with the Launchpad team, so that we can have a better chance of avoiding these surprise failures.