We seem to be getting a bit beyond the scope of this particular bug.
I'm a bit alarmed by what seem to be unnecessary client-breaking API
changes in launchpadlib. I'm all for breaking APIs if there's a good
reason, but I don't understand the reasons for these changes at the
Client applications do rely on these things being URLs, either because
they are trying to work around lplib bugs or lacunae (eg having no
constant for LPNET, having no web_url property), or because they just
simply want the actual URL to access in other ways. For instance
txrestfulclient and wrested don't use Launchpadlib to do the actual
http calls but they do (or could) use these constants rather than
hardcoding the URLs themselves.
See for instance
If you want to add symbolic constants for the tokens 'production' etc,
by all means do. That is very much in the spirit of getting clients
away from specifying URLs when they don't really care about the
particular URL. However please add a new symbol for that rather than
repurposing an existing well defined symbol.
> 4. If I were to change the constant LPNET_SERVICE_ROOT so that it was
> 'production' instead of 'https://api.launchpad.net/api/', this should
> have no effect on clients. Unless, some client is assuming that
> LPNET_SERVICE_ROOT is a URL and doing URL manipulation on the value.
They do assume it's a URL. It's always been a URL, and the term
'service root' is I think generally understood to mean a URL.
> So, coming back to your original statement:
> "At the moment in Ubuntu's stable release, they must either hardcode a
> URL or do the moral equivalent through string manipulation, because
> there is no symbol for LPNET_SERVICE_ROOT"
> In Ubuntu's stable release, there is a symbol for LPNET_SERVICE_ROOT:
> it's uris.LPNET_SERVICE_ROOT. You can also use the string "production".
> If it turns out people would rather use uris.LPNET_SERVICE_ROOT than
> "production", I would like to change the value of
> uris.LPNET_SERVICE_ROOT to "production".
Sorry, I was confused by the move from launchpadlib.launchpad.* to
> Otherwise, people might get the
> idea that they can do URL manipulation on these constants, when they're
> actually supposed to be nothing but useful constants for people to pass
> into login_with().
Why does it matter?